1

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.

What Does OOM Actually Mean?

OOM stands for Out Of Memory.

The Linux kernel can invoke its OOM handling mechanism when it cannot satisfy memory allocation requirements under the relevant constraints.

That distinction is extremely important.

An OOM event can happen because of system-wide memory pressure, a container memory limit, a cgroup restriction, or a particular allocation that cannot be satisfied.

RAM Usage Percentage Can Be Misleading

A common monitoring dashboard might display:

Memory usage: 87%

That number alone doesn’t tell you whether the system is healthy.

Linux uses RAM for multiple purposes, including:

• Application memory
• Filesystem page cache
• Kernel memory
• Buffers
• Reclaimable memory
• Shared memory
• Memory used by containers

Some of this memory can be reclaimed, while some cannot.

That’s why commands such as:

free -h

are often more useful than looking at a single “used memory” percentage.

Pay particular attention to:

available

The available value provides an estimate of how much memory can be given to applications without significant memory pressure.

The Difference Between Used and Available

Consider:

             total        used        free      buff/cache   available

Mem:           16Gi        14Gi        300Mi        1.7Gi        1.2Gi

It would be easy to see 14 GB used and assume that only 2 GB remain.

But Linux doesn’t divide memory into simply “used” and “unused.”

Some of the memory counted as used may be reclaimable. The kernel can potentially release cache pages to satisfy new allocations.

Therefore, a server can have relatively high memory usage without immediately being in an OOM condition.

The real concern is what happens when reclaimable memory is insufficient or when an allocation cannot be satisfied within a specific memory limit.

Memory Pressure Is the Bigger Picture

Memory pressure occurs when the system is struggling to provide memory to processes.

One symptom is increased reclaim activity.

Linux may attempt to reclaim memory by:

• Releasing filesystem cache
• Reclaiming kernel objects
• Swapping memory to disk
• Reusing available memory

If these mechanisms aren’t sufficient, the kernel may eventually invoke OOM handling.

This means memory pressure can build before a dashboard reaches 100% RAM usage.

OOM Can Happen Inside Containers

Containers are one of the most common reasons administrators encounter an OOM event without the host appearing completely out of memory.

Suppose a physical server has:

64 GB RAM

But a container has a memory limit of:

4 GB

The container cannot necessarily consume the server’s entire 64 GB.

If processes inside that container collectively reach the configured memory limit, the container’s cgroup can experience an OOM event.

The host might still have plenty of unused memory.

For example:

Host RAM:          64 GB

Host available:    20 GB

Container limit:    4 GB

Container usage:    4 GB

The container can encounter OOM conditions even though the host is nowhere near 100% memory usage.

This is why containerized workloads require investigation at both the host level and cgroup level.

Check for OOM Events

When investigating an unexpected process termination, start with kernel logs.

Try:

dmesg | grep -i -E “oom|out of memory|killed process”

On systemd-based systems:

journalctl -k | grep -i -E “oom|out of memory|killed process”

The kernel log may identify the process that was killed and provide additional information about the memory condition.

For container environments, also inspect the container runtime and orchestration platform’s events and metrics.

Check Cgroup Memory Limits

On systems using cgroups, memory availability can be constrained by limits imposed on a service or container.

For example, a service might have a configured memory limit even though the physical server has plenty of RAM.

Depending on the cgroup version and configuration, useful information can be found under:

/sys/fs/cgroup/

On modern cgroup v2 systems, files such as:

memory.current

memory.max

memory.events

can provide valuable information.

For example, memory.events can help reveal whether memory-related events, including OOM conditions, have occurred within a cgroup.

The exact paths and available files depend on the Linux distribution and cgroup configuration.

Swap Changes the Picture

Swap is another important part of memory-pressure analysis.

Check:

free -h

and monitor activity using:

vmstat 1

In vmstat, the si and so columns show memory being swapped in and out.

Heavy and sustained swap activity can indicate that the system is under memory pressure.

However, simply having some swap in use doesn’t automatically mean the system is failing. Linux may move relatively inactive pages to swap while keeping frequently accessed data in RAM.

The important question is whether the system is experiencing ongoing memory pressure and performance degradation.

Some Allocations Are Harder to Satisfy

Another subtle issue is that not every memory allocation is equally easy to satisfy.

Certain kernel operations may require particular types of memory or contiguous physical pages. Memory fragmentation and allocation constraints can therefore matter in some situations.

This is one reason why:

“RAM isn’t 100% used”

doesn’t necessarily guarantee:

“Every possible memory allocation can succeed.”

Linux memory management involves more than simply counting free gigabytes.

How to Investigate an OOM Event

A structured investigation is much more effective than immediately increasing RAM.

Start by collecting:

free -h

Then inspect processes:

ps aux –sort=-%mem | head -20

Check kernel events:

journalctl -k | grep -i -E “oom|out of memory|killed process”

Monitor memory pressure:

vmstat 1

If containers or services use cgroups, inspect their memory limits and events.

Finally, compare the event with historical monitoring data. Determine whether memory usage increased gradually, spiked suddenly, or remained relatively stable while a specific workload hit a configured limit.

Conclusion

An OOM event does not always mean that the server’s physical RAM reached 100% utilization.

Linux memory management is based on availability, reclaimability, allocation requirements, swap, and resource limits. In containerized environments, cgroup limits can produce OOM events even while the host has significant RAM available.