{"id":18130,"date":"2026-10-06T23:02:20","date_gmt":"2026-10-07T05:02:20","guid":{"rendered":"https:\/\/www.supportpro.com\/blog\/?p=18130"},"modified":"2026-10-06T23:02:51","modified_gmt":"2026-10-07T05:02:51","slug":"diagnosing-oom-events-when-there-is-no-swap","status":"publish","type":"post","link":"https:\/\/www.supportpro.com\/blog\/diagnosing-oom-events-when-there-is-no-swap\/","title":{"rendered":"Diagnosing OOM Events When There Is No Swap"},"content":{"rendered":"\n

Running a Linux system without swap can provide predictable performance, especially in environments where disk-based memory is undesirable. However, removing swap also means that the operating system has fewer options when physical RAM becomes exhausted. Once available memory reaches a critical level, Linux may trigger an Out-Of-Memory (OOM) event and terminate one or more processes to recover memory.<\/p>\n\n\n\n

An unexpected OOM event can be confusing because the application that gets terminated is not necessarily the only process responsible for memory pressure. Diagnosing the problem requires looking at system memory, individual processes, kernel messages, and the timing of the failure. This article explains a practical approach to investigating OOM events on systems that operate without swap.<\/p>\n\n\n\n

Understanding What Happens During an OOM Event<\/h2>\n\n\n\n

Every running process requires memory for its code, data, libraries, buffers, and other resources. The Linux kernel normally manages this memory dynamically. When available RAM becomes critically low, the kernel attempts to reclaim memory through mechanisms such as dropping filesystem caches.<\/p>\n\n\n\n

If memory cannot be reclaimed quickly enough and there is no swap space available, the kernel may reach a point where it cannot satisfy new memory allocation requests. This is when the OOM mechanism can become active.<\/p>\n\n\n\n

The kernel evaluates running processes and selects a process to terminate according to several factors. Therefore, it is not accurate to assume that the process using the largest amount of RAM will automatically be killed. The OOM decision depends on the process’s memory usage, its adjustment settings, and other kernel considerations.<\/p>\n\n\n\n

Start by Checking Memory Availability<\/h2>\n\n\n\n

The first step in troubleshooting is to determine whether the machine actually ran out of physical memory.<\/p>\n\n\n\n

A simple command such as:<\/p>\n\n\n\n

free -h<\/p>\n\n\n\n

provides an overview of total, used, available, and cached memory.<\/p>\n\n\n\n

Pay particular attention to the available value rather than simply looking at the amount labelled “free.” Linux uses unused RAM for filesystem caching, and that memory can often be reclaimed when applications need it.<\/p>\n\n\n\n

You can also inspect detailed memory information with:<\/p>\n\n\n\n

cat \/proc\/meminfo<\/p>\n\n\n\n

This exposes values such as MemTotal, MemAvailable, Cached, Buffers, and other memory-related statistics. Comparing these values over time can help reveal whether memory consumption gradually increased before the OOM event.<\/p>\n\n\n\n

Examine Kernel Messages<\/h2>\n\n\n\n

Kernel logs are among the most useful sources of information after an OOM event. The kernel normally records details about the memory shortage and the process selected for termination.<\/p>\n\n\n\n

On systems using systemd, try:<\/p>\n\n\n\n

journalctl -k<\/p>\n\n\n\n

You can search for OOM-related entries with:<\/p>\n\n\n\n

journalctl -k | grep -i oom<\/p>\n\n\n\n

Another useful command is:<\/p>\n\n\n\n

dmesg | grep -i -E ‘oom|out of memory|killed process’<\/p>\n\n\n\n

Depending on the Linux distribution and logging configuration, the exact messages may differ.<\/p>\n\n\n\n

These records can reveal when the OOM condition occurred, which process was terminated, and sometimes how much memory different processes were consuming. This information is considerably more useful than simply checking which application disappeared.<\/p>\n\n\n\n

Identify the Memory-Hungry Processes<\/h2>\n\n\n\n

After confirming that an OOM event occurred, the next step is to identify applications that were consuming significant amounts of memory.<\/p>\n\n\n\n

The top command provides a live overview:<\/p>\n\n\n\n

top<\/p>\n\n\n\n

For a more convenient interface, htop can also be useful if it is installed.<\/p>\n\n\n\n

Look at columns such as RES, which represents resident memory currently held in RAM. A process with continuously increasing resident memory may indicate a memory leak or uncontrolled workload growth.<\/p>\n\n\n\n

However, memory usage should be interpreted carefully. Some memory may be shared between processes, meaning that simply adding the displayed memory values can produce misleading totals.<\/p>\n\n\n\n

Check for Gradual Memory Growth<\/h2>\n\n\n\n

Not every OOM event is caused by a sudden spike. In many cases, an application slowly consumes additional memory until the machine eventually reaches its limit.<\/p>\n\n\n\n

Monitoring tools can help identify this pattern. Even a basic periodic command can provide useful evidence:<\/p>\n\n\n\n

watch -n 5 free -h<\/p>\n\n\n\n

For production systems, dedicated monitoring solutions can record memory utilization over hours or days. Historical graphs are particularly valuable because they show whether memory usage is steadily climbing, fluctuating with workload, or suddenly increasing.<\/p>\n\n\n\n

A gradual upward trend may point toward a memory leak, an expanding cache, excessive concurrency, or a workload that requires more resources than the server provides.<\/p>\n\n\n\n

Investigate Containers and Services<\/h2>\n\n\n\n

Modern Linux systems often run applications inside containers. In such environments, an OOM event may be related to a container memory limit rather than the total physical RAM of the host.<\/p>\n\n\n\n

For Docker-based systems, inspect container statistics with:<\/p>\n\n\n\n

docker stats<\/p>\n\n\n\n

Container orchestration platforms can also impose memory limits on individual workloads. A container may therefore encounter an OOM condition even when the host still has some available memory.<\/p>\n\n\n\n

This distinction is important. Always determine whether the OOM event occurred at the host level, inside a container, or within another resource-controlled environment.<\/p>\n\n\n\n

Examine the OOM Score<\/h2>\n\n\n\n

Linux uses an OOM scoring mechanism when selecting processes during memory pressure. The value can be inspected through the process information directory.<\/p>\n\n\n\n

For example:<\/p>\n\n\n\n

cat \/proc\/<PID>\/oom_score<\/p>\n\n\n\n

There is also an adjustment value:<\/p>\n\n\n\n

cat \/proc\/<PID>\/oom_score_adj<\/p>\n\n\n\n

These values can influence how likely a process is to be selected during an OOM situation. This is useful when investigating why a particular process was terminated instead of another process with apparently similar memory usage.<\/p>\n\n\n\n

Look Beyond RAM Usage<\/h2>\n\n\n\n

A complete investigation should not focus exclusively on one application’s RAM consumption. Memory pressure can involve several components, including filesystem caches, shared memory, kernel memory, memory mappings, and multiple applications consuming moderate amounts of RAM simultaneously.<\/p>\n\n\n\n

It is also useful to check whether a service experienced a workload change shortly before the incident. A sudden increase in users, requests, database activity, background jobs, or file processing can explain why memory requirements increased.<\/p>\n\n\n\n

Preventing Future OOM Events<\/h2>\n\n\n\n

Once the cause has been identified, prevention becomes the next priority. Possible solutions include reducing application memory usage, fixing memory leaks, limiting concurrency, increasing physical RAM, or configuring appropriate resource limits.<\/p>\n\n\n\n

If the system is intentionally designed without swap, monitoring becomes even more important because there is less room for temporary memory pressure. Alerts should be configured before RAM reaches a critical level so administrators have an opportunity to investigate.<\/p>\n\n\n\n

Conclusion<\/h2>\n\n\n\n

Diagnosing an OOM event on a Linux system<\/a> without swap requires looking beyond the process that was terminated. The killed process is often only the final result of overall memory pressure, which may have been caused by a gradual memory leak, sudden workload increase, excessive concurrency, container limits, or insufficient physical RAM. Reviewing free, \/proc\/meminfo, kernel logs, process memory usage, and container statistics can help identify what happened before and during the OOM event.<\/p>\n\n\n\n

Once the underlying cause is identified, administrators can take appropriate preventive measures, such as optimizing application memory usage, fixing memory leaks, adjusting workloads or resource limits, increasing physical memory, and improving monitoring. On systems intentionally configured without swap, proactive memory monitoring and alerts are especially important because there is less capacity to absorb temporary increases in memory demand. A combination of system-level and application-level analysis can help prevent recurring OOM events and maintain reliable system performance.<\/p>\n\n\n\n

\n

Facing issues? <\/p>\n\n\n\n

Our technical support
engineers can solve it. <\/p>\n\n\n\n\"Contact<\/a><\/span>