What Is Memory Pressure on Mac?

The short answer. Memory pressure is macOS’s replacement for the free-memory number, and it exists because “how much memory is free” is a useless question on a modern operating system. The graph in Activity Monitor answers the question that actually matters — is the system able to give memory to whatever asks for it — and it is green, yellow or red. Green means stop looking; red means the machine is spending its time moving pages instead of running your work.

This guide explains what the numbers measure, why a Mac showing 95 percent memory used is usually fine, and how to tell a memory problem from the three other things that produce the same symptom.

Why “free memory” is the wrong number

An operating system with a lot of free memory is wasting it. Memory that is not holding anything is memory that could be making something faster, so every modern system uses spare RAM as a cache: files read from disk stay resident in case they are read again, and are dropped the instant something needs the space.

That produces a counter-intuitive reading. A Mac that has just been used heavily shows almost all of its memory in use, because the cache filled up. A Mac that was just restarted shows a lot free. Neither number tells you anything about whether the machine has enough memory, because the first machine will release its cache on demand and the second will fill it again within an hour.

The old habit of watching “free” and worrying when it approaches zero is measuring the cache, not the pressure. macOS still shows the number — under Cached Files in Activity Monitor — but it is not the one to judge by.

The four numbers that matter

Open Activity Monitor and select the Memory tab. The panel at the bottom lists five figures, and each measures something different.

Two relationships explain the rest.

Memory Used = App Memory + Wired + Compressed. It does not include Cached Files, which is why the pie chart and the numbers can look inconsistent until you know what is in each.

Cached Files is free memory that is being useful. When something needs memory, macOS takes it from here first, instantly, because the content can always be re-read from disk. A machine with 12GB in Cached Files has 12GB it can hand over at a moment’s notice.

Wired memory deserves a note because it is the only figure that is genuinely unavailable. It is the kernel and its data structures, and on a healthy Mac it sits at one to three gigabytes. A wired figure that climbs over days indicates a leak in a kernel extension or a driver, and it is one of the few memory problems that a restart only postpones.

The pressure graph

The graph at the bottom of the panel is the answer, and it is computed from three things: how much memory is available without evicting anything important, how much compression is happening, and how much swapping is going on.

Green. The system can satisfy any reasonable request. Compression may be active, cache may be large, and none of it matters.

Yellow. The system is compressing and swapping to keep up. It is still working, and you may notice nothing, or you may notice a slight delay when switching to an app that has been idle for a while.

Red. The system is spending significant time moving pages to and from disk. Everything that needs memory is now waiting on storage, and the machine feels slow in the specific way that memory exhaustion produces: the interface responds, then stalls, then responds.

The reason this is a better indicator than any single number is that it is a rate, not a level. A machine at 95 percent with a green graph is compressing a little and serving everything from memory. A machine at 70 percent with a red graph is thrashing — it has enough total memory but the wrong pages are resident, and it is swapping constantly to fix that.

Swap, and why it is not the villain

Swap gets blamed for problems it does not cause, largely because the number only goes up and never comes down.

When macOS needs memory and nothing can be evicted, it writes a page that has not been used recently to a swap file on the SSD and reclaims the memory. When that page is needed again, it is read back. This is slower than keeping it in memory and vastly faster than not having the memory at all.

The swap file grows as needed and does not shrink when the pressure drops. A Mac that had a busy afternoon shows several gigabytes of swap used for the rest of the week, and that is fine — it is a high-water mark, not a current condition. The number to watch is not Swap Used but whether it is still growing while you work.

Two things are worth knowing about swap on modern Macs. On Apple Silicon the SSD is fast enough that swapping is far less painful than it was on a hard disk, which is why a machine can be under pressure without feeling broken. And swap writes count against SSD wear, though the volume of writes involved in normal use is far below what would matter over the life of the machine.

Reading it from the command line

Activity Monitor is the right tool for a glance. Terminal is better for a record.

vm_stat

prints the page counts: free, active, inactive, speculative, wired, compressed. Multiply by the page size — 16KB on Apple Silicon, 4KB on Intel — to get bytes. vm_stat 1 repeats every second, which is how you see whether the numbers are moving.

memory_pressure

prints the system’s own assessment as a percentage of free memory and, on current versions, the pressure level. It is the same computation the graph uses.

sysctl vm.swapusage

gives total, used and free swap in one line.

For a live view in the menu bar, iStat Menus and Stats both show memory pressure, compressed memory and swap as a graph, which is more useful than a number because the shape tells you when the pressure spikes — during a build, during a video export, when a particular app is open. TaskExplorer adds per-process detail with the signing information attached, which is how you tell a legitimate helper from something that should not be running.

What a leak looks like

A memory leak is a process that holds memory it will never release. The signature in Activity Monitor is a Memory column that climbs steadily over hours and does not fall when the app is idle.

Three patterns are worth distinguishing:

A genuine leak. Monotonic growth, no plateau, and the app eventually becomes unusable or the system runs out. Quitting the app releases the memory, which confirms it was the app’s.

A cache that grows to a limit. Growth followed by a plateau, then reuse. Browsers do this deliberately — they keep decoded images and back/forward pages in memory because re-fetching them is slower. Not a leak, and not a problem.

Wired memory growth. The kernel’s pinned memory climbing over days, which no application quit will release. This points at a driver or a kernel extension, and a restart is the only immediate fix. If it recurs, the extension is the suspect.

To find the culprit, sort by Memory and watch for a few minutes rather than taking one reading. A single snapshot cannot distinguish a leak from a large working set; a trend can.

What unified memory changes

On Apple Silicon the CPU, GPU and Neural Engine share one pool of memory rather than each having its own. That has two consequences for anyone reading these numbers.

The good one: no copying. On an Intel Mac with integrated graphics, a texture or a frame has to be copied from system memory to graphics memory and back, which costs time and doubles the footprint. On Apple Silicon there is one copy, and the GPU reads the same bytes the CPU wrote. For workloads that move data between CPU and GPU — video editing, machine learning, games — this is the largest single reason the newer machines feel different.

The awkward one: the GPU’s memory is inside the same figure. A video export or a 3D render will show as memory used by a process you may not associate with memory at all, and the machine’s total is shared rather than divided. On an 8GB machine this is why a browser with many tabs and a video call at the same time can put you in the yellow: everything is drawing from one pool, and the GPU cannot have “its own” memory to fall back on.

There is no setting for this and nothing to tune. It is worth knowing because it explains a class of “why is my memory full when I am only doing one thing” question that has a real answer.

Why some apps report more than they use

The Memory column in Activity Monitor is a useful ranking and a poor measurement, and three categories of application make it worse.

Browsers share memory between processes. Each tab is a renderer, each extension is a process, and the GPU process holds the compositor’s memory. Activity Monitor will list a dozen processes whose names are the site titles, and the browser’s own total is the sum. Sorting by Memory puts one tab at the top, which is misleading: the tab is not using four gigabytes, the browser is.

Virtual machines reserve their configured RAM up front. A VM allocated 8GB shows 8GB whether the guest is using 200MB or 7.5GB, because the host has promised the memory to the guest. That memory is not available to anything else even when it is idle inside the guest, which is why running a VM on a 16GB machine feels like running it on an 8GB machine.

Electron applications are Chromium with a bundled renderer, so every one of them is a browser in the memory sense. A chat client, a note-taking app and a code editor built on Electron can together use more memory than everything else on the machine, and each one will look modest in isolation because the cost is spread across helper processes.

The practical fix is to look at the sum per application rather than at the top process. Activity Monitor’s View menu has All Processes, Hierarchically, which groups the helpers under their parent — which is the only view in which a browser’s real footprint is visible.

Two more commands

footprint is the tool Apple’s own engineers use, and it is more accurate than Activity Monitor’s figure because it accounts for shared pages and compressed memory properly:

footprint -p <pid>

It reports the physical footprint, the peak, and a breakdown of what the process is holding. For a machine where Activity Monitor’s numbers do not add up to the total — which happens because shared memory is counted once but attributed to several processes — this is the tool that resolves it.

ps gives a quick per-process resident size without any interpretation:

ps -axo pid,rss,comm -r | head -20

rss is resident set size in kilobytes, sorted descending. It is a cruder number than footprint and it is available on every machine without installing anything, which makes it the right first look when you are on a machine that is already struggling.

When pressure is a symptom rather than a cause

One case is worth calling out because it inverts the diagnosis: a machine with a full disk can show red memory pressure without being short of memory.

Swap needs somewhere to go. When the startup disk has almost no free space, macOS cannot grow the swap file, so pages that would have been written out have to stay resident, so the compressor works harder, so the pressure climbs. The machine is not short of RAM; it is short of disk, and the memory pressure is reporting the consequence.

The tell is the combination: red pressure, a nearly full disk, and a swap figure that is not growing even though the pressure is high. The fix is in how to speed up a slow Mac, not here — free the space and the pressure drops without closing a single application.

Watching it without watching it

The practical difficulty with memory pressure is that the moment you want to look at it is the moment the machine is too slow to open Activity Monitor.

Two solutions. A menu bar monitor — iStat Menus and Stats both do this — puts the graph where you can see it without switching apps, and the history is what makes it useful: you can see that pressure went yellow at 14:20, when the export started, rather than guessing. The cost is a small amount of memory for the monitor itself, which is a fair trade for a machine you are trying to diagnose.

The other is to let the system tell you. sudo sysctl kern.memorystatus_vm_pressure_level reports the current level as a number, and a launchd job or a shell loop can log it over a day, which turns “it feels slow sometimes” into a record with timestamps. It is the same technique the panic log uses: capture the state while it is happening, because the machine’s own memory of the event is more reliable than yours.

When memory is actually the bottleneck

Four symptoms, and they are specific enough to be diagnostic.

The machine stalls when switching to an app that has been idle. That app’s pages were swapped out and have to come back. It is the clearest sign of pressure.

Activity Monitor shows red. Obvious, and worth checking rather than assuming.

Swap Used is growing while you watch. Not the total, the trend. A machine that is stable at 4GB of swap is fine; one that climbs from 4 to 6 while you sit there is under pressure now.

The stall correlates with a specific workload. Opening a second virtual machine, importing a large photo library, running a build with several parallel jobs. Those are the workloads that need memory in bulk, and they are the ones that reveal a machine that is short.

What is not a symptom: a high Memory Used figure, a large Cached Files figure, or a process using several gigabytes. Those are all normal.

What to do about it, in order

1. Find what is holding the memory. Sort by Memory in Activity Monitor. The answer is usually a browser with many tabs, a virtual machine, or a photo or video editor with a large project open.
2. Quit, do not hide. An app that is hidden or minimised still holds its memory. Command-Q releases it; closing the window often does not.
3. Reduce the working set rather than the app count. Ten browser tabs of a heavy web app cost more than a hundred tabs of text. Closing the ten is the move.
4. Restart. It clears leaked memory, wired memory growth and stale caches at once. It is not a fix, but it is a reset that costs ninety seconds.
5. Check the login items. A background helper that is leaking memory is invisible until you look at the list. System Settings → General → Login Items.
6. Consider whether the machine has enough memory for the work. If the same workload puts you in the red every day, the answer is not a cleanup, it is a machine with more memory — and on Apple Silicon that decision cannot be made later.

How much memory is enough

The honest answer depends on the workload, and because Apple Silicon memory is not upgradeable, it is worth getting right at purchase.

The number that surprises people is 8GB. It is genuinely adequate for the first row and genuinely tight for the second, because a modern browser will happily use four gigabytes on its own. If you are choosing between more storage and more memory on a machine you will keep for five years, memory is the one that cannot be added later.

FAQ

Does memory pressure affect battery life? Indirectly. A machine under pressure runs the CPU harder, compresses more and writes to swap, all of which draw power. The effect is smaller than display brightness or a runaway process, but a machine that is constantly swapping is a machine working harder than it needs to.

Why does kernel_task use so much memory? Because it is the kernel, and wired memory is counted there. A figure in the low gigabytes is normal. A figure that grows steadily over days is a leak in a driver or extension.

Is compressed memory slower than swap? Usually faster, which is why macOS compresses before it swaps. Compression and decompression cost CPU time; a swap round trip costs storage latency. On an SSD the difference is smaller than it was on a hard disk, and compression is still the first choice because it avoids the write entirely.

Can I clear memory manually? Not in any way that helps. Tools that “free” memory by forcing pages out make the next access slower, because the pages have to come back. macOS manages this itself and does it better than a timer-based utility can.

Does a restart really help? For a leak or for wired memory growth, yes — it is the only thing that does. For ordinary pressure caused by your workload, no: the same apps will fill the same memory again within an hour. Restarting is a diagnostic and a reset, not a cure.