If you have ever run free -h on a Linux server and noticed that the free memory value is surprisingly low, your first reaction might be: “Is the server running out of RAM?” Usually, the answer is no. One of the most common misunderstandings about Linux memory management is assuming that low “free” memory automatically means low available memory. Linux is designed to use unused RAM for useful work, including filesystem caches and buffers. As a result, a healthy Linux system can show very little completely unused memory while still having plenty of memory available for applications. Understanding the difference between free, used, cached, and available memory can help you troubleshoot Linux servers much more accurately. What Does “Free Memory” …
Linux
Keeping a server operating system up to date is essential for security, compatibility, and long-term stability. For hosting servers running cPanel, however, an operating system upgrade can be more complicated than a standard package update. This is where cPanel ELevate can help. ELevate is designed to simplify the process of upgrading supported Linux distributions while preserving the existing cPanel and hosting environment. If you are managing a server running an older version of CentOS, AlmaLinux, or CloudLinux, understanding how ELevate works can help you plan a safer migration. What Is cPanel ELevate? cPanel ELevate is a migration tool from cPanel that helps administrators move supported cPanel servers from an older operating system version to a newer supported version. Instead of …
Virtual machines make it possible to run multiple workloads on the same physical infrastructure. This improves resource utilization and provides flexibility, but it also introduces performance characteristics that systems engineers must understand. One of the most useful metrics when troubleshooting CPU performance inside a virtual machine is CPU steal time. CPU steal time represents time when a virtual CPU (vCPU) is ready to run, but the hypervisor is giving the underlying physical CPU to another virtual machine or workload. From inside the guest operating system, this time can look like unexplained CPU performance loss. Understanding steal time can help engineers distinguish between a problem inside the guest operating system and CPU contention occurring at the virtualization layer. What Is CPU …
Tracing One TCP Connection Through the Linux Kernel From connect() to the NIC
When a Linux application connects to a remote service, the operation looks simple: connect() But behind this single system call, the Linux networking stack performs several steps before a TCP packet reaches the physical network interface. The request passes through the socket layer, TCP implementation, routing subsystem, packet-processing hooks, queuing mechanisms, and finally the network device driver. Understanding this path is useful when troubleshooting connection delays, packet drops, unexpected routes, high CPU usage, or network performance problems. This article follows one outbound TCP connection from an application to the NIC. 1. The Application Calls connect() Consider a simple application connecting to a web server: connect(sockfd, (struct sockaddr *)&server, size of(server)); The application does not construct an Ethernet frame or TCP …
One of the most confusing Linux memory problems is an Out-Of-Memory (OOM) event occurring when RAM usage doesn’t appear to be at 100%. You might check the server and see that only 80–90% of physical memory is being reported as used. Yet an application gets killed, a container is terminated, or the kernel reports an OOM event. At first, this seems impossible. If the server still has RAM available, why would Linux kill a process? The answer is that memory pressure is more complicated than a simple RAM-usage percentage. Linux considers reclaimable memory, allocation requirements, swap, cgroups, memory limits, and other constraints when deciding whether memory is available. Understanding these concepts makes seemingly mysterious OOM events much easier to diagnose. …
A sudden increase in memory usage on a Linux server can be confusing and stressful, especially when everything appeared normal just a few minutes earlier. A memory spike doesn’t always mean that the server has a memory leak or that it is about to run out of RAM. Temporary workload increases, filesystem caching, application behaviour, background jobs, containers, and kernel activity can all contribute to higher memory usage. The key is to investigate what changed, which process consumed the memory, and whether the memory can be reclaimed. This guide walks through a practical approach to investigating sudden memory spikes on Linux servers. 1. Confirm That Memory Usage Actually Increased Before investigating individual processes, confirm that the system is experiencing a …
Memory leaks are among the most frustrating performance problems on a Linux hosting server. A server may run normally for hours or even days, then gradually consume available RAM until applications slow down, processes terminate, or the entire system becomes unstable. Unlike a sudden CPU spike, a memory leak can be difficult to identify because memory usage often increases gradually. The good news is that Linux provides several powerful tools to monitor memory, identify problematic processes, and determine whether an application is actually leaking memory. This guide explains a practical approach to investigating memory leaks on a Linux hosting server. What Is a Memory Leak? A memory leak occurs when a running application allocates memory but fails to release it …
The Server Wasn’t Out of RAM: Investigating a Linux OOM Event From Kernel Logs
When a production server suddenly kills a process, the first assumption is often simple: the server ran out of memory. That assumption can be misleading. Linux can invoke the Out-Of-Memory (OOM) killer even when monitoring dashboards show apparently available RAM. The reason is that Linux memory management is more complicated than looking at one number such as free memory. Allocation constraints, memory zones, cgroups, fragmentation, reserved memory, and kernel behavior can all contribute to an OOM event. Recently, I investigated an OOM incident where the server appeared to have enough RAM. The kernel logs told a different story. The First Clue: The Kernel Log The investigation started with the usual commands: dmesg -T | grep -i -E “oom|out of memory|killed …
A production server can look completely healthy from the outside and still be experiencing a serious kernel problem. The server may still respond to some network requests. SSH might work intermittently. Monitoring may report that the machine is online. Yet applications can become extremely slow, CPUs can remain busy, and kernel log messages can reveal that a CPU has been stuck executing kernel code for an unusually long period. This can be confusing during an incident because a soft lockup is not the same thing as a server crash or complete system hang. The key is to understand what Linux is actually reporting. The First Clue: “CPU Stuck” The investigation usually starts with the kernel log. You might see something …
When a Linux system faces severe memory pressure, the kernel must decide which process to terminate to free memory. This is where the Linux Out-Of-Memory (OOM) killer comes into play. The OOM killer is a last-resort mechanism. When the kernel cannot satisfy memory allocations after reclaiming available memory and taking other measures, it may terminate one or more processes to recover memory and keep the system running. But how does Linux decide which process to kill? It doesn’t simply choose the process using the most RAM. Linux uses a scoring mechanism that considers factors such as memory usage and administrator-defined adjustments. Understanding OOM scores can help you investigate unexpected process termination and configure critical services more carefully. What Is the …