Mac memory pressure: what the number means and when it misleads

Memory pressure is not a measure of how full your RAM is. It is the kernel's judgement about whether it can keep meeting demand without doing something expensive. A Mac can sit at 90% occupied and be fine. It can sit at 60% and be struggling.

That gap is why the numbers get read wrong. This page covers what each one actually counts, which to trust, and what a genuine shortage looks like when it arrives.

The short answer

Three signals, in order of usefulness.

Free memory is not on that list, and neither is swap size. Both are commonly quoted and both mislead, for reasons below.

Why three tools disagree about the same Mac

At one moment on a 48 GB machine, three tools described memory three different ways, and all three were correct.

The spread between 84% free and 4 GB free is not rounding. It is a disagreement about where "in use" ends and "available if you ask" begins. Most of a healthy Mac's memory is in the middle: holding something useful, and released the moment something else needs it more.

Free memory near zero is the design working

A healthy macOS system drives free memory toward zero deliberately. A page sitting on the free list is doing nothing. A page holding file cache is doing something useful and can still be handed over instantly.

Apple's own definition points the same way: the Activity Monitor memory pressure graph is determined by free memory, swap rate, wired memory, and file cached memory together, and Apple's guidance on whether a Mac needs more RAM reads that graph rather than a free-memory figure.

Measured on the machine above: an 8 GiB allocation, with every page touched so it was genuinely resident, drove free memory from 4.05 GB to 0.24 GB and speculative pages from 52,981 to 159. Watching free memory, that looks like an emergency. Swap stayed at exactly zero and the kernel never left its normal state. macOS reclaimed cache instead of refusing the request, which is what it is supposed to do.

The categories, and where they come from

These are not invented by any monitoring tool. They are fields of vm_statistics64, declared in XNU's osfmk/mach/vm_statistics.h, and vm_stat prints from the same structure.

Available memory is the sum of the bottom four. It is the number that answers whether another application, or another model, will fit.

Pressure is a state, not a percentage

Memory pressure in the macOS sense is a discrete kernel state, readable as an integer:

sysctl kern.memorystatus_vm_pressure_level
# 1 = normal, 2 = warning, 4 = critical

Those are the same three levels Apple exposes to applications through a memory pressure dispatch source, as DISPATCH_MEMORYPRESSURE_NORMAL, WARN and CRITICAL. The sysctl and the dispatch source are two views of one decision.

It is worth reading alongside a utilisation figure rather than instead of one, because they disagree in both directions. A machine can sit at 60% working set while the kernel is already warning, and at 90% with the kernel entirely relaxed. In a measured two-model run the kernel reported warning for a single sample and returned to normal while the machine still held a 43 GB working set and had written 225 MB to disk.

What a real shortage looks like

macOS does not fall over when memory runs short. It escalates through three responses, each more expensive than the last, and only the third is something you feel.

Read left to right and the order is the point. Free memory is spent first because it is free. The compressor takes the next share, peaking at 17.17 GB. Only when both are exhausted does anything reach disk.

The consequence for diagnosis is that swap activity is not an early warning. By the time it appears, the two cheaper mechanisms have already been used up.

Swap size and swap traffic are different questions

This is the most common misreading, and it goes wrong in both directions.

Allocation is sticky. macOS does not eagerly reclaim swap space once the pressure that created it has passed. In the run above, with both models unloaded and 17.80 GB free, vm.swapusage still reported 0.23 GB allocated and the cumulative counters had stopped moving entirely. A tool reporting only swap used would have called that machine constrained while it sat idle.

Allocation also lags upward. A machine one minute into a genuine shortfall can be actively paging while the allocated total is still small. The stall is already happening; the number people watch has barely moved.

Direction matters more than volume. In that same run, 13,756 pages were written out and swapins stayed at exactly zero. Nothing was ever read back, so no thread ever waited on a page, and the machine stayed responsive throughout. Swap-out alone is the system tidying up. It is swap-in that produces the pause you feel, because a thread cannot continue until its page returns.

sysctl vm.swapusage                    # the level, sticky and lagging
vm_stat | grep -E "Swapins|Swapouts"   # run twice, subtract, multiply by page size

The counters are cumulative page counts, so only the difference between two readings means anything. Multiply by the page size, which is 16384 on Apple Silicon and worth confirming with sysctl hw.pagesize rather than assuming.

Reading the three together

The third row is the one worth internalising. Low available memory on its own is not a fault condition. Low available memory plus sustained two-way swap traffic is.

Sizing: what actually occupies memory

If the question is whether something will fit, file size is a poor proxy and the error is largest for small things. Measured across five local models on the same machine, resident cost while running ranged from 88% to 195% of file size: a 2.78 GB model occupied 5.43 GB, while a 15.21 GB model occupied 14.90 GB.

The fixed overhead of a loaded process does not shrink in proportion to its data. Size against measured occupancy, not against a file listing.

Compression does not rescue this either. macOS absorbed 8.59 GB of zero-filled test allocation into 3.75 GB of working-set growth, because zeroes compress almost perfectly. Real data does not. Treat that ratio as an artefact of the test, not a rule.

What to do when pressure is genuinely high

Check the state before acting. Red in Activity Monitor and a warning-level sysctl mean the kernel agrees with you. Low free memory alone does not.

Close what holds memory, not what is merely open. A background application at rest costs little. One holding a large working set costs whatever it holds.

Do not size against free memory. It sits near zero by design on a healthy Mac. Available memory is the meaningful figure.

Restarting works, and it is worth knowing why. It discards accumulated working sets and stale swap allocation. That is not evidence a restart was necessary, only that it is effective.

Checking your own machine

sysctl kern.memorystatus_vm_pressure_level   # 1 normal, 2 warning, 4 critical
sysctl vm.swapusage                          # allocation, sticky
sysctl hw.pagesize                           # 16384 on Apple Silicon
vm_stat                                      # every page category
memory_pressure                              # the system's own summary

Everything above ships with macOS. Nothing here requires installing anything.

Where these numbers come from

The runs behind this page, with full method and per-sample figures: which number tells you a model won't fit for the three-tool disagreement and the 8 GiB allocation, swap I/O vs swap size for the sticky-allocation trace, what a second model costs for the escalation table, five models on one Mac for the resident-cost range, and unified memory for how the GPU draws on the same pool.

Definitions for every value named here are in the metric reference. If the machine is slow but memory is not the cause, thermal throttling covers the other common explanation. And watching these numbers over time is the monitors' job: five free Mac system monitors are compared side by side, licence and running cost included.

Sources

• View memory usage in Activity Monitor on Mac, Apple Support
• Check if your Mac needs more RAM in Activity Monitor, Apple Support
• osfmk/mach/vm_statistics.h, XNU source
• DISPATCH_SOURCE_TYPE_MEMORYPRESSURE, Apple Developer Documentation