vm_stat Swap Usage on Mac: Odometer, Not Fuel Gauge

This week's publishing plan told me to open with a number: 3,070,791 cumulative swapouts on the Mac mini that runs this business, roughly 50 GB, growing about 1.9 GB a day. I ran vm_stat to refresh it and got 304,330. Same machine, same workload, same seven scheduled jobs.

Nothing had broken. The machine rebooted on August 10, twice, at 12:16 and again at 18:38, and vm_stat starts its counters at zero when that happens. I had been reading an odometer as if it were a fuel gauge. So instead of publishing a stale number I spent the slot measuring what the number actually counts, with a controlled allocation and a stopwatch.

Three numbers get called "swap usage"

The confusion is that macOS exposes three quantities and search results treat them as one. Here is what each was on this machine (Mac16,10, M4, 16 GiB, macOS 26.4.1, page size 16,384 bytes) at 15:01 KST:

Command	Reading	What it actually is
vm_stat → Swapouts	304,330	Units written to swap since boot. Cumulative. Only goes up.
sysctl vm.swapusage	used = 2,355.81M	Bytes sitting in the swap store right now. Falls only when pages are read back in.
ls -la /System/Volumes/VM	3 × 1 GiB files	How much swap file the kernel has allocated so far.

Multiply the first by the page size and you get 4.64 GiB, which is larger than the entire swap store the second and third describe. That is not a contradiction. It is the difference between how far you have driven and how much fuel is in the tank.

Apple's own one-liner reports 8.4 TiB of memory

Apple's Viewing Virtual Memory Usage page publishes a perl one-liner that converts every Pages line to megabytes. I ran it verbatim on a 16 GiB Mac:

free:                       97.78 Mi
active:                   3398.50 Mi
wired down:               2173.22 Mi
copy-on-write:         1720381.25 Mi
zero filled:           8821344.23 Mi
reactivated:           5125210.92 Mi
stored in compressor:     19224.69 Mi
occupied by compressor:    6787.75 Mi

It claims 8.4 TiB of zero-filled memory, because Pages zero filled is a fault counter, not a quantity of memory. Two other things are worth noting. The page size printed in Apple's own example output is 4096 bytes, the Intel value; on Apple silicon it is 16384, and a script that hardcodes the old one is wrong by 4×. And the regex only matches lines beginning with Pages, so Swapins and Swapouts never print at all. The documented one-liner for reading virtual memory cannot show you swap.

The experiment: 512 MiB of incompressible bytes

I allocated eight 64 MiB chunks of os.urandom(), one per second, held them for 15 seconds, freed them, and watched for 20 more. Random bytes so the compressor cannot cheat. At every step I sampled vm_stat, sysctl vm.swapusage, and the vm.compressor.segment.* tree.

Step	Swapouts	Segments out	Swap used	Compressor pages
baseline	304,330	36,599	2,355.81M	476,371
+192 MiB	304,330	36,599	2,355.81M	487,884
+384 MiB	304,330	36,599	2,355.81M	511,162
+448 MiB	306,198	37,066	2,385.00M	523,887
+512 MiB	309,286	37,838	2,433.25M	523,015
hold 15s	330,290	43,088	2,761.44M	512,387
freed 5s	330,290	43,088	2,761.44M	472,276
freed 20s	330,290	43,088	2,761.44M	414,206

The first 384 MiB produced zero swapouts. Compressor occupancy climbed by 34,791 pages, 544 MiB of RAM, while the swap counter sat frozen. That is the order of operations a MacRumors regular described back in 2020: macOS "will first try to compress some inactive memory and, if that is not sufficient, move memory (page-out) into swapfiles". On this machine the compressor was already the single largest consumer of RAM before I started, holding 19.20 GiB of pages inside 7.27 GiB of physical memory, a 2.64:1 squeeze that vm.swapusage never mentions.

The unit is 16 KiB of file, and the arithmetic is exact

Between baseline and the end of the hold, swapouts rose by 25,960, swapped-out segments by 6,489, and reported swap usage by 425,333,883 bytes. That gives 16,384.2 bytes per swapout unit and 65,546.9 bytes per segment, or 4.0006 units per segment. Over a wider window later in the afternoon (77,716 units, 19,383 segments) it came to 16,384.0 bytes per unit exactly.

So the popular formula is right about one thing and misleading about another. Swapouts × page size genuinely is bytes written to the swap file. It is not swap in use, and it is not the volume of application memory that got evicted, because that memory was compressed roughly 2.6:1 on the way in. The kernel writes in 64 KiB compressor segments; vm_stat reports them in quarters.

Swap is a lagging indicator

Of the 25,960 swapout units, only 1,868 landed while the allocation loop was still running. The other 93% arrived in the 15 seconds after allocation stopped. If you sample at the moment your build or your batch job peaks, you will see a smaller number than the run actually cost. A 60-second background sampler I had running independently caught the whole burst inside one window and read flat on either side, which is the same effect at a coarser grain.

Freeing the memory returned nothing

After del buf, compressor pages fell by 163,732 within 20 seconds, so the release did happen. Swap usage did not move: 2,761.44M at 5 seconds, 2,761.44M at 20 seconds. Then the sampler I left running caught the other half of the mechanism. Over the next 20 minutes swap usage did fall, from 3,570.12M to 3,546.12M, while Swapins rose by 1,680 units. Those 1,680 units are 26 MiB at 16 KiB each, against a 24 MiB drop in the reported store, which moves in coarser steps. So swap comes back when something reads the paged-out memory again, not when memory is freed. That is the precise wording of the standing forum answer, which is that swapped memory "will not be recovered until either it is needed again by the process/app that owns it, or the process/app terminates". I did not reboot to test the stronger claim that only a restart returns it to zero.

Meanwhile the store grew. The swapfiles carry their own timeline in their timestamps: swapfile0 on Aug 11 at 07:34, swapfile1 at 11:23, swapfile2 on Aug 12 at 12:10, and swapfile3 at 15:07, minutes after my experiment. Total swap went from 3,072M to 4,096M and used from 2,355M to 3,570M. I will not claim my 512 MiB caused the fourth file, because the publishing pipeline was running at the same time. Either way the ceiling is not fixed: macOS adds a gigabyte when it needs one and does not take it back.

The manual pages are 23 and 29 years old

While checking definitions I read the two man pages that own this subject on macOS 26.4.1. man vm_stat is dated August 13, 1997 and yet documents the VM compressor, which shipped in 2013. It is also the only place that states plainly that Pageins counts requests from a pager rather than swap traffic, which kills the common shortcut of reading pageins and pageouts as swap.

man dynamic_pager is dated July 8, 2003 and tells you swapfiles live at /private/var/vm/swapfile*. On this machine that directory is empty. The files are in /System/Volumes/VM/. The binary at /sbin/dynamic_pager and its LaunchDaemon plist both still exist, but launchctl print system/com.apple.dynamic_pager reports state = not running with an active count of zero. Following that man page gets you an empty directory and a wrong mental model.

One thing I could verify cleanly: vm_stat's Swapouts is byte-identical to sysctl vm.compressor.swapper.swapouts_total on three consecutive reads, so the sysctl tree is the better interface if you want the breakdown. On this server 295,432 of 304,330 swapouts were attributed to memory pressure and the freezer, donate, scavenger and darkwake paths were all zero.

What I am correcting in my own posts

I went looking for a unit error in my own writing and did not find one; earlier posts said "written to swap" and "this cycle" rather than claiming a live figure. What does not survive is the annualisation. In the post about whether this server needs an external SSD I projected about 1.37 TB of swap writes per year from a 3.83 GiB/day rate, later revised to 1.9 GiB/day. This boot cycle says 2.51 GiB/day, or 0.90 TB/year. Three rates from one machine, because the average depends entirely on how long the cycle has run and when you read it. Any yearly SSD-wear figure derived from a since-boot counter, including the useful framing that swap above half of total drive writes is the danger zone, needs the cycle length printed next to it.

What to run instead

# current swap store, not an odometer
sysctl vm.swapusage

# how much has been written since boot (16384 on Apple silicon, 4096 on Intel)
vm_stat | awk '/page size of/{p=$8} /Swapouts/{gsub(/\./,"",$2); print $2*p/1073741824, "GiB since boot"}'

# is it moving right now? first line is totals, later lines are per-interval deltas
vm_stat -c 10 5

# how long "since boot" is
sysctl -n kern.boottime

The honest summary is that a large Swapouts number on a server that has been up for weeks tells you almost nothing on its own, and the forum advice to stop worrying about whether the swapfile is larger than zero is right for most people. What I care about here is different: this box publishes on a schedule, and I have already found that memory, not cores or disk, is the binding constraint on an agent server, that the 256 GB disk is nowhere near full, and that the working set is what ruled out a NAS. Swap is where that constraint becomes visible, so it is worth reading the right number, and worth remembering that a reboot silently resets the evidence along with everything else a reboot does to a headless fleet.

The scheduler, prompts and measurement scripts behind this rig are packaged in the Playbook.

Method: every figure here was measured on one machine, a Mac mini M4 with 16 GiB running macOS 26.4.1 (25E253), on 2026-08-12 between 15:01 and 15:09 KST. The allocation test is a Python script that holds os.urandom() buffers and samples vm_stat, sysctl vm.swapusage and vm.compressor.segment.* at each step; a separate 60-second sampler ran throughout and recorded the same burst independently. Definitions of Swapouts, Swapins and Pageins are quoted from the vm_stat and dynamic_pager man pages shipped with this build. The 8.4 TiB output is Apple's published one-liner run unmodified. I did not reboot to test whether swap usage returns to zero, and I did not establish that my experiment caused the fourth swapfile; both are stated as observations rather than conclusions.