What Is Memory Pressure?

What Is Memory Pressure?

Memory pressure means the system is running short of easily available memory and has to work harder to satisfy new memory requests.

Memory pressure occurs when a system has difficulty providing enough memory for applications and processes that need it. As available memory falls, the operating system has to work harder to reclaim memory, remove cached data, use swap, or take other actions to satisfy new memory requests.

Memory pressure does not simply mean that most of your RAM is being used. Linux intentionally uses unused memory for caches, so a server with high memory utilization can still be healthy. Pressure becomes important when applications begin waiting for memory, reclaim activity increases, swap becomes active, or the system approaches an out-of-memory condition.

In severe cases, memory pressure can slow applications, increase latency, cause Kubernetes pods to be evicted, or trigger the Linux Out-of-Memory (OOM) killer.

Memory Pressure at a Glance

How Does Memory Pressure Work?

Applications continuously allocate and release memory. The operating system also uses memory for the filesystem cache, kernel data structures, buffers, and other purposes, so physical RAM is usually shared between many different types of workloads.

When free memory becomes limited, Linux first tries to reclaim memory that can be reused. Cached file pages, for example, may be removed because the data can be read from disk again if needed.

As pressure increases, the system may spend more time reclaiming memory or moving less-active pages to swap. If it cannot free enough memory to satisfy new allocations, it may eventually reach an out-of-memory state and terminate processes to recover memory. Linux PSI can measure the amount of time tasks are stalled because of memory contention, including severe states where all non-idle tasks are stalled.

A simplified progression looks like this:

Memory demand increases → Available memory falls → Memory reclaim increases → Swapping or stalls may increase → Performance degrades → OOM risk increases

What Causes Memory Pressure?

Memory pressure usually appears when demand approaches or exceeds the memory that a system can provide efficiently. This may happen because application traffic grows, more processes are started, workloads receive insufficient memory, or several memory-intensive services run on the same host.

Memory leaks are another common cause. An application may continually allocate memory without releasing it, causing available memory to fall gradually until the system begins reclaiming aggressively or runs out of memory.

Short workload spikes can create pressure as well. A batch job, large database query, cache warm-up, application deployment, or sudden increase in concurrent requests may cause memory consumption to rise quickly even if normal usage is healthy.

Containers can make memory management more complex because applications operate within cgroup memory constraints as well as the physical limits of the node. A workload may therefore run into its own memory limit even when the underlying host still has memory available.

High Memory Usage vs. Memory Pressure

High memory usage and memory pressure are related, but they are not the same thing.

Linux uses otherwise-unused RAM to cache files and improve performance. This means a system can report relatively little completely free memory while still having plenty of memory that can be reclaimed for applications.

For this reason, available memory is generally more informative than free memory alone. Linux's MemAvailable estimates how much memory can be given to new applications without swapping and takes reclaimable caches and system memory requirements into account.

Datadog follows a similar approach with system.mem.usable, which uses Linux MemAvailable when it is available. This avoids treating all cached memory as unavailable to applications.

What Happens During Memory Pressure?

The operating system normally tries to recover memory before taking more disruptive action. It can reclaim cached pages and other reclaimable memory so that new allocations can proceed.

As pressure becomes stronger, applications may spend more time waiting for memory reclaim. If swap is configured, less-active anonymous memory may also be moved out of RAM, which can introduce additional storage I/O and latency.

At extreme levels, the machine can begin thrashing, where significant time is spent reclaiming, swapping, and waiting instead of performing useful application work. Linux's PSI documentation describes sustained full memory stalls as a severe performance condition.

If the system still cannot satisfy memory requests, Linux may invoke the OOM killer and terminate one or more processes to free memory.

How Does Memory Pressure Affect Application Performance?

Memory pressure can affect an application before the machine actually runs out of memory. Memory reclaim consumes CPU resources, while swapping can introduce additional disk access and make application memory significantly slower to access.

An API may therefore experience higher response times even though CPU usage and request traffic appear normal. Databases, JVM applications, caches, build workloads, and other memory-intensive services can be particularly sensitive to reduced memory availability.

As pressure becomes severe, request queues may grow, throughput can fall, processes may become unresponsive, and applications can eventually be terminated by the OOM killer.

This is why waiting for an OOM event is usually too late. Available memory, reclaim behavior, memory stalls, swap activity, and application latency can provide earlier warning.

What Is Memory Pressure in Kubernetes?

In Kubernetes, MemoryPressure is a node condition that indicates available memory has crossed a configured eviction threshold. It is not simply a label for high pod memory utilization.

The kubelet continuously monitors resources on each node. For memory, it evaluates the memory.available signal and compares it with configured eviction thresholds. If the threshold is met, the node can report:

MemoryPressure=True

Kubernetes also adds the node.kubernetes.io/memory-pressure taint, which helps prevent additional workloads from being scheduled onto the affected node.

If memory remains constrained, the kubelet can reclaim node-level resources and then evict pods to preserve node stability. If memory disappears too quickly for the kubelet to react, the Linux OOM killer may act first.

Kubernetes Memory Pressure vs. OOMKilled

MemoryPressure and OOMKilled describe different situations.

MemoryPressure is a node-level condition showing that available node memory has crossed an eviction threshold. Kubernetes may respond by avoiding new scheduling on the node and evicting selected pods.

OOMKilled means a process was terminated because a memory limit or available memory condition could not be satisfied. A container can also be OOM-killed because it exceeds its own memory limit even when the entire Kubernetes node is not under MemoryPressure.

This distinction is important when troubleshooting. A single container repeatedly being OOM-killed may point to an incorrect limit or application memory problem, while several workloads degrading on a node can indicate broader node memory pressure.

How Do You Monitor Memory Pressure?

Memory pressure should be monitored as a combination of capacity and performance signals rather than one percentage.

Available memory is a useful starting point because it shows how much additional workload the system can support without immediately needing swap. Memory utilization, swap activity, page reclaim, OOM events, and Linux PSI provide additional context about how hard the system is working to satisfy allocations.

In Kubernetes, node MemoryPressure conditions, available node memory, pod memory usage, container limits, evictions, and OOM events should be viewed together. If several pods become slow while node-level available memory falls and PSI rises, memory contention becomes a stronger investigative lead.

Application signals also matter. Increasing request latency or falling throughput at the same time as rising memory pressure provides much stronger evidence of user impact than a memory percentage alone.

What Is a Good Memory Pressure Level?

There is no universal memory utilization percentage that indicates healthy or unhealthy memory pressure.

A server using 90% of RAM may still be healthy if much of that memory is reclaimable cache and applications are not stalling. Another server at a lower utilization level may already be experiencing problems because the remaining memory cannot be reclaimed easily.

For Linux, focus on trends in MemAvailable, PSI, swap activity, reclaim behavior, and OOM events rather than choosing a single RAM utilization threshold. Baselines should also reflect the workload because a database server and a stateless API may behave very differently under the same memory utilization.

For Kubernetes, eviction thresholds provide a more concrete operational boundary because the kubelet uses them when deciding whether the node is under memory pressure.

How Do You Reduce Memory Pressure?

The right fix depends on what is consuming memory. If an application has a leak or unexpectedly growing heap, increasing the machine's RAM may only delay the same failure.

Start by identifying which processes, containers, or workloads are consuming memory and whether usage is expected. Check recent deployments, traffic increases, background jobs, cache growth, and changes in application behavior.

If the workload genuinely requires more memory, increasing node or VM capacity may be appropriate. In Kubernetes, memory requests and limits should also reflect real workload behavior so that pods are scheduled onto nodes with enough capacity and unnecessary OOM events are avoided.

Scaling horizontally can also reduce memory demand per instance for workloads that support it. For caches and memory-heavy applications, adjusting cache sizes or application memory settings may free enough headroom without adding infrastructure.

Swap and kernel memory settings can affect how Linux handles pressure, but they should be tuned carefully. Changing swappiness, disabling swap, or modifying reclaim behavior without understanding the workload can move the problem rather than solve it. Red Hat notes that aggressively avoiding swap can increase the likelihood of the OOM killer being invoked under memory-intensive workloads.

How to Troubleshoot High Memory Pressure

Start by determining whether the system is actually under pressure or simply using a large amount of RAM. Check MemAvailable, PSI, swap activity, and application performance rather than looking only at memory utilization.

Next, identify which processes or containers are consuming memory and whether their usage has changed. A gradual upward trend may suggest a memory leak, while a sudden increase may correspond to traffic, a batch job, deployment, or cache growth.

For Kubernetes, check whether MemoryPressure=True, look for pod evictions and OOM events, and compare memory usage with pod requests and limits. Also compare affected nodes because pressure on one node while similar nodes remain healthy can point toward uneven workload placement.

Finally, correlate memory behavior with user-facing signals. If available memory is falling while PSI and application latency rise together, the evidence for memory-related performance degradation is much stronger.

The Bottom Line

Memory pressure occurs when applications and the operating system compete for limited memory strongly enough that allocating new memory becomes increasingly expensive. Linux responds by reclaiming memory, potentially using swap, and eventually invoking the OOM killer if it cannot recover enough capacity.

The best indicators are not simply total memory utilization. Available memory, Linux PSI, swap and reclaim activity, OOM events, and application performance provide a more accurate picture of whether memory demand is creating real pressure.

In Kubernetes, memory pressure also has a specific operational meaning. The kubelet monitors available node memory, marks nodes with MemoryPressure when eviction thresholds are met, and may eventually evict pods to protect the node.