Fixing macOS Memory Pressure and 'Out of Application Memory' Warnings

A macOS system warning that “your system has run out of application memory,” or Activity Monitor’s Memory tab showing a persistently red or yellow memory pressure gauge, points at a genuinely different situation than what the same symptom would mean on many other operating systems — macOS’s memory management is deliberately aggressive about using available RAM, which means some of what looks alarming is actually working as intended, while a smaller subset is a genuine problem worth fixing.

Why swap usage alone isn’t automatically a problem

macOS uses available memory aggressively for disk caching and compressed memory to improve overall performance, and swapping some inactive memory out to disk under normal operation is an expected, by-design part of that strategy — seeing a non-zero “Swap Used” figure in Activity Monitor’s Memory tab is not, by itself, evidence of a problem. The memory pressure graph (not raw swap usage) is the metric actually designed to indicate whether the system is under genuine strain: green means the system is comfortably managing current memory demand (even with some swap in use), while sustained yellow or red indicates real, ongoing pressure that’s actually affecting performance.

Identifying what’s actually driving sustained pressure

Activity Monitor’s Memory tab, sorted by the “Memory” column, identifies which specific processes are consuming the most memory right now — but for diagnosing a leak specifically (a process whose memory usage grows continuously rather than settling at a stable working set), watching that same figure over time for one specific suspect process is more informative than a single snapshot:

while true; do ps -o rss,comm -p <PID>; sleep 30; done

A process whose resident memory (RSS) climbs steadily and never plateaus over an extended period, without a corresponding increase in actual workload, is exhibiting genuine leak behavior worth investigating specifically — rather than simply being a large, memory-hungry-but-stable application doing legitimately memory-intensive work.

The specific case of browser tabs and memory

Web browsers are overwhelmingly the most common source of gradually accumulating memory pressure on a typical Mac, since modern browsers run each tab (or group of related tabs) as a separate process, and a small number of poorly-behaved web pages — often ones with memory-leaking JavaScript, or pages left open and actively running scripts for extended periods — can each individually accumulate substantial memory over time. Checking a browser’s own built-in task manager (Chrome’s Shift+Esc, or the equivalent in other Chromium-based browsers; Safari’s Develop menu > “Show JavaScript Console” and per-tab activity) to identify which specific tab is the actual culprit, rather than assuming the browser as a whole is simply “using too much memory,” usually resolves this category of pressure by closing just the offending tab rather than the entire browser.

When it’s a specific application with a genuine bug

For a specific, identified non-browser application that shows genuine unbounded growth, checking whether an update is available (memory leaks are ordinary bugs that get fixed in normal update cycles) is the first step, and if no update resolves it, periodically quitting and relaunching that specific application is a reasonable practical workaround while waiting for an upstream fix — meaningfully different from a system-wide reboot, since it targets just the process actually responsible rather than disrupting everything else currently running.

Ruling out too many resource-heavy applications running simultaneously at once

Sometimes sustained memory pressure isn’t a leak in any single application at all — it’s simply the aggregate demand of several genuinely memory-intensive applications (video editing software, virtual machines, large numbers of browser tabs, IDE and language-server processes) running simultaneously exceeding what the installed RAM comfortably supports. In this case, the accurate diagnosis is that the workload has outgrown the machine’s installed memory, and the practical options are closing some of the concurrently-running memory-intensive applications, or, if this is a recurring pattern rather than an occasional peak, considering a hardware upgrade path if the Mac supports one, since no software-side fix resolves a workload that’s genuinely too large for the installed RAM.

Why not to reflexively reach for third-party “memory cleaner” utilities

Third-party utilities claiming to “free up” or “optimize” memory on macOS are working against, not with, macOS’s own memory management strategy — forcibly evicting cached memory that macOS was deliberately holding onto for performance reasons doesn’t create new usable capacity, it just forces the system to redo caching work it had already done, often making subsequent performance worse rather than better. Identifying and addressing the actual process responsible for genuine pressure, as described above, is the approach that actually resolves the underlying cause rather than temporarily and counterproductively fighting macOS’s own memory manager.

What “compressed” memory actually means

Before macOS resorts to writing inactive memory out to disk as traditional swap, it first tries memory compression: pages of RAM that haven’t been touched recently get compressed in place, using a fast, purpose-built algorithm (WKdm) designed specifically for the low-latency demands of this exact use case, freeing up physical RAM for active use while keeping the compressed data available for near-instant decompression the moment it’s needed again — considerably faster than a genuine round-trip to disk-based swap. Activity Monitor’s Memory tab shows a “Compressed” figure separately from “Swap Used” for exactly this reason: compressed memory is a normal, first-line strategy that costs comparatively little in performance, while swap is the heavier, slower fallback used only once compression alone isn’t enough to relieve pressure.

Reading memory pressure from Terminal directly

memory_pressure

For a quicker, scriptable check than opening Activity Monitor, the memory_pressure command-line tool reports the same underlying pressure level macOS’s own memory management uses internally, along with page-in/page-out statistics — useful for logging pressure state over time, or checking it quickly over an SSH session on a headless or remote Mac where opening Activity Monitor’s GUI isn’t practical at all.

Related:

Sources: