Free, active, inactive, wired: what your Mac's memory categories mean

At the moment I took this reading, this 24 GB MacBook Pro reported 876 MB unused. Nothing was wrong. Activity Monitor showed green, no application was slow, and the machine had been running for weeks. Free memory is close to zero on a healthy Mac by design, and understanding why requires knowing what the other categories hold.

vm_stat

The categories, on a real machine

Apple Silicon uses a 16,384 byte page, so every page count multiplies by 16,384 rather than by the 4,096 that older documentation assumes.

Category	Pages	Size	Reclaimable?
Free	52,869	826 MiB	Already available
Active	415,384	6.34 GiB	Only under pressure
Inactive	416,199	6.35 GiB	Yes, immediately
Speculative	4,068	63.6 MiB	Yes, immediately
Wired	195,479	2.97 GiB	Never
Purgeable	14,984	234 MiB	Yes, on request

2.97 GiB

Free

Memory holding nothing. On a Mac that has been running for more than a few minutes this is small, because the kernel fills spare memory with caches rather than leaving it idle. A high free figure after weeks of uptime would suggest the system had recently been forced to dump a large amount of cached data, which is a symptom rather than a goal.

Active

Pages that have been touched recently and are considered in use. This is closest to the everyday meaning of “memory an application is using”. Under pressure the kernel can move these to inactive, but it prefers not to.

Inactive

The category that causes the most confusion. Inactive pages hold data that was used and has not been touched lately: a file you read, an application you switched away from, a library that was loaded and is now idle. The data is still there and still valid.

If a process needs memory, inactive pages are handed over immediately. If instead you return to that application, the data is already resident and it resumes instantly. Inactive memory is a bet that you might come back, and the bet costs nothing because it is abandoned the moment the space is wanted.

Counting inactive memory as “used” makes a healthy machine look full. Counting it as “free” makes a struggling machine look fine. It is genuinely neither.

Speculative

Pages the kernel read ahead of being asked, guessing you would want the next part of a file you are reading sequentially. Cheap to produce and the first thing discarded.

Wired

Memory that cannot be paged out or compressed under any circumstances: kernel structures, drivers, and the parts of running processes that must always be resident. 2.97 GiB of this machine is permanently unavailable to anything else.

Wired is the only figure here that behaves the way people assume all memory figures behave. It is genuinely consumed.

Purgeable

Pages an application has explicitly marked as discardable, usually caches it can rebuild. The application is telling the kernel it may take these back without warning.

The arithmetic that does not work

Add the categories that describe where memory physically is:

free          52,869
active       415,384
inactive     416,199
speculative    4,068
wired        195,479
             -------
             1,083,999 pages  =  16.54 GiB

The machine has 25,769,803,776 bytes, which is 1,572,864 pages, or 24 GiB. The visible categories account for about 64 percent of it. Roughly 8.6 GiB is unaccounted for.

64%

The remainder is held by the memory compressor, which reports separately:

Pages occupied by compressor:            433,288

That is 6.61 GiB of physical memory holding compressed data. The compressor is not one of the five categories above; it is a consumer of memory alongside them. Any attempt to reconcile vm_stat without including it will always leave a gap, and on this machine the gap is large enough to look like a bug.

Why “free” is the wrong number to watch

The free figure tells you how much memory is currently sitting empty. It does not tell you whether the system can satisfy the next allocation quickly, which is the thing you actually care about.

A machine with 876 MB free and 6.35 GiB inactive can hand out 7 GiB immediately, because inactive pages are dropped without ceremony. A machine with 876 MB free and no inactive pages, everything wired and compressed, is in real trouble. Both report the same free number.

The figures that distinguish those two states are memory pressure, which reports how hard the kernel is working to find pages, and swap usage, which reports whether it has resorted to disk. Both are one command each:

memory_pressure -Q
sysctl vm.swapusage

A note on reading these twice

Two vm_stat samples taken minutes apart on this machine differed noticeably. Free pages moved from 9,128 to 52,869, active rose, inactive rose, and wired barely moved. Nothing happened in between beyond ordinary use.

These are instantaneous readings of a system that continuously rebalances. A single sample tells you what was true at one moment. Watching the trend across several samples, particularly of swap and pressure, tells you something about how the machine is coping. One reading, compared against someone else’s one reading, tells you nothing at all.

The counters that describe activity rather than state

The page counts describe where memory is right now. A second group of counters describes what has happened, and they are cumulative since boot rather than instantaneous.

vm_stat | grep -E "Pageins|Pageouts|Swapins|Swapouts|Compressions|Decompressions"

On the machine sampled here:

Counter	Value	What it means
Compressions	588,645,523	Pages compressed since boot
Decompressions	491,673,004	Pages decompressed on access
Pageins	110,040,957	Pages read from disk
Pageouts	5,318,449	Pages written to disk
Swapouts	7,652,945	Pages written to swap
Swapins	5,032,125	Pages read back from swap

The ratio between compressions and swapouts is the useful part: 588 million against 7.6 million, so compression is the routine path and swap is the exception. The exception has still been taken millions of times.

Because these are cumulative since boot, a single reading tells you little. The rate of change is what matters, and getting it means two readings a known interval apart:

A=$(vm_stat | awk '/Swapouts/ {gsub(/[^0-9]/,""); print}')
sleep 60
B=$(vm_stat | awk '/Swapouts/ {gsub(/[^0-9]/,""); print}')
echo "$(( (B - A) )) swapouts in 60s"

A machine at rest produces a small number. A machine under memory pressure produces a large and sustained one, and that is a far better indicator than any of the instantaneous page counts.

Two numbers to watch instead of free

If you take one thing from this, it is which figures actually indicate a problem.

memory_pressure -Q
sysctl vm.swapusage

memory_pressure reports a system-wide free percentage that accounts for reclaimable memory rather than only genuinely idle pages, so it answers the question people think free answers. On this machine it reported 58 percent while free pages were under a gigabyte.

vm.swapusage reports whether the machine has resorted to disk. Sustained growth there, with a consistent workload, is the clearest evidence that memory is genuinely short. Everything else on this page is context for interpreting those two.

A note on Activity Monitor’s version of this

Activity Monitor presents the same underlying data with different labels, and the mapping is not obvious. Its Memory Used figure combines app memory, wired memory and compressed memory, which is why it reads far higher than anything in vm_stat taken alone. Cached Files corresponds roughly to the inactive and speculative pages here.

The Memory Pressure graph is the most useful thing in that window and the least understood. It is not a measure of how much memory is in use; it is a measure of how hard the kernel is working to satisfy allocations. Green with 95 percent of memory allocated is a healthy machine using what you paid for. Yellow or red with the same allocation figure is not.