Mac memory pressure: reading the graph before closing everything

The usual sequence goes like this. Something feels slow, Activity Monitor gets opened, the Memory tab shows a graph with a band of yellow in it, and the next twenty minutes go into quitting browser tabs and force quitting whatever sits at the top of the list. Sometimes the machine feels better afterwards. Often it does not, and the graph is yellow again within an hour.

The graph is worth understanding before acting on it, because it does not measure what most people assume. It is not a fuel gauge. A Mac that shows almost all of its RAM in use is not a Mac in trouble, and a Mac showing a red graph will not be fixed by closing three windows. Getting the reading right is the difference between a change that holds and an afternoon of busywork.

What the memory pressure graph actually measures

Apple's own description is short and worth taking literally. In the Activity Monitor guide, memory pressure "graphically represents how efficiently your memory is serving your processing needs," and it is "determined by the amount of free memory, swap rate, wired memory, and file cached memory."

Read that list again. Free memory is only one of four inputs, and the other three are all about behaviour rather than capacity. Swap rate is how often the system is moving pages between RAM and the startup disk. Wired memory is the portion the kernel has locked in place and cannot move. File cached memory is data the system parked in otherwise idle RAM on the chance it gets asked for again.

That last one is why the gauge idea breaks down. macOS deliberately fills spare RAM with cached files. Apple describes cached files as "the size of files cached by the system into unused memory to improve performance," and notes that "until this memory is overwritten, it remains cached, so it can help improve performance when you reopen the app." Empty RAM does no work. A well behaved system keeps very little of it.

So the graph is not answering "how full is memory." It is answering a harder question: is the system able to give each process the pages it wants without paying a penalty. When the answer is yes, the graph stays low and flat no matter how much RAM is technically in use. When the answer is no, it climbs, and the reason it climbs is that the system has started paying for the shortfall with time.

Green, yellow and red, and what each one is telling you

Apple's guidance on the three colours is unusually blunt. Green means "your computer is using all of its RAM efficiently." Yellow means "your computer might eventually need more RAM." Red means "your computer needs more RAM."

Three things follow from that wording, and all three get missed.

First, green does not mean there is headroom. It means the current workload is being served without penalty. A 16 GB machine running a browser with sixty tabs can be solidly green. The colour is a verdict on efficiency, not on how much is left.

Second, yellow is a statement about the future, not the present. "Might eventually need more RAM" is a forecast. A brief band of yellow while a large file opens, followed by green, is the system doing its job. Yellow that appears within minutes of every login and stays there is the forecast being made seriously.

Third, red is Apple saying the hardware is the constraint. On a Mac with soldered memory, which is every Apple silicon Mac, that is not a setting anyone can change. It is either a different workload or a different machine. Apple's own next step in that situation is to check whether the model even supports an upgrade: hold Option, choose Apple menu > System Information, then look at Hardware > Memory and the Memory Slots pane for an Upgradeable Memory line. On models where upgrades are not possible, that pane may not appear at all.

The colour also has to be read over time. A single glance is close to worthless, because pressure spikes constantly during ordinary work. Leaving the window open through a normal working hour, or watching the graph in the Dock icon, gives a shape instead of a snapshot, and the shape is what matters.

The numbers beside the graph, and which ones are worth reading

Apple lists six figures in the bottom of the Memory pane. They are not equally useful.

Reading	What it reports	How much it tells you
Physical Memory	The amount of RAM installed	Fixed. Context only
Memory Used	The amount of RAM being used	Almost always high. Weak signal
App Memory	Memory being used by apps	Useful for finding one greedy process
Wired Memory	Memory the system requires and cannot cache or page out	Rises with drivers and background services
Compressed	Memory compressed to make more RAM available	Evidence of squeeze, not yet of failure
Cached Files	Files cached into unused memory to improve performance	High is normal and good
Swap Used	Space used on the startup disk to swap files to and from RAM	The number that reflects real cost

Memory Used is the figure people quote and the one that misleads most, because cached files count toward it. Wired memory deserves more attention than it gets: Apple describes it as "memory required by the system to operate," which "can't be cached and must stay in RAM, so it's not available to other apps." Kernel extensions, virtual network interfaces, disk encryption tools and similar low level software raise it, and nothing a user closes brings it back down.

Compressed memory is the interesting middle state. When a Mac approaches its limit, inactive apps in memory get compressed to free room for active ones. Apple notes that the Compressed Memory column can be turned on in Activity Monitor to see the VM Compressed figure per app. Compression costs processor time rather than disk time, which is why a machine can sit at high compression and still feel responsive.

Swap used is the number that reflects real cost

Compression is cheap. Swapping is not. Swap Used is space on the startup disk being used to hold pages that did not fit in RAM, and every page that has to come back is a disk read standing between a keystroke and the screen.

Absolute swap is less informative than its direction. A few gigabytes of swap accumulated over a week of uptime is a historical record, not a live problem, because pages that went out and were never needed again cost nothing further. Swap that grows steadily during a single session, and a pressure graph that climbs with it, is the combination that explains a sluggish machine.

For a reading that does not depend on interpretation, the command line tool vm_stat reports the raw counters, including Swapins, documented as "the total number of compressed pages that have been swapped back in from disk," and Swapouts, "the total number of compressed pages that have been swapped out to disk." Swapins are the ones that cost the user time, because they are pages the system had to go and retrieve. Running it twice a few minutes apart and comparing the swapin figure says more than any colour.

There is a second, quieter cost. Swap writes land on the internal drive, and on a Mac where the drive is also soldered in, sustained heavy swapping is wear that cannot be replaced separately. That is not a reason to panic over a few gigabytes. It is a reason not to treat constant heavy swapping as a stable way to work.

What closing apps actually buys you

Quitting a large application does free its App Memory, and if the pressure graph was climbing because of that one application, the graph drops and stays down. That is the case where closing things is exactly right.

The other cases look similar and behave differently. Closing browser tabs in a browser that has already compressed the inactive ones returns memory that was costing very little. Force quitting the process at the top of the sorted list often removes something whose pages were inactive and already compressed. Freeing cached files, which some cleanup utilities advertise, throws away work the system did on purpose and tends to be followed by the same files being read from disk again.

A more productive way to sort the list is to look at what is resident that was never opened. Activity Monitor's list includes background agents, helper processes, sync clients, update checkers and menu bar residents, and none of them appear in the Dock or in the window list. They tend to be small individually. A dozen of them, each holding a modest amount of wired and app memory and each waking periodically, is a fixed tax on every session, paid before the first document is opened.

That is a different kind of finding from a single greedy application, and it calls for a different response. One large process is a decision about that one application. Fifteen small residents is a decision about what gets to start up at all, which lives in System Settings > General > Login Items and Extensions, where both the login items and the background permissions are listed.

The menu bar as an inventory of what is resident

There is a practical shortcut to that audit, and it is the row of icons along the top right of the screen. Most of those icons belong to processes that launched at login and have been running ever since. Reading the menu bar from left to right is the fastest way to see what a Mac is actually hosting, without sorting a list of process names that mean nothing.

The problem is that on a laptop screen the row is usually longer than the space available for it, so the leftmost icons are simply not drawn, and the ones that are missing are exactly the ones that have been forgotten. Software installed a year ago and never opened since keeps its icon at the far left, out of sight, with its helper process still resident.

Two honest caveats belong here. Hiding an icon does not free a byte of memory, because the icon and the process are separate things. And a tool that organises the menu bar is itself another resident process. What a menu bar organiser does provide is the inventory: the full list, visible on demand, which is what makes it possible to decide what to remove for real. A menu bar organiser that keeps hidden items reachable lets the row stay short without losing track of what is in it, and the decision that follows, uninstalling two things that have not been opened in six months, is the one that changes the wired memory figure.

Habits, settings, or hardware

Once the graph has been read over a few hours, the choice is usually between three levels of intervention, and they are not interchangeable.

Situation	What the graph looks like	What actually helps
One application dominates	Green, with spikes tied to that app	Change how that app is used. Fewer documents open, fewer tabs, a lighter alternative
Many small residents	Yellow early, wired memory high	Remove what is not used. Fewer login items and background agents
Workload exceeds the machine	Red most of the day, swapins climbing	More RAM, or move the heavy work elsewhere

The middle row is the one most often skipped, because it takes half an hour of auditing and produces no dramatic number. It is also the only one of the three that is free.

What to change first

Leave Activity Monitor open on the Memory tab through one ordinary working hour and note the shape of the graph rather than its current colour, then check whether swapins are still rising at the end of it. If the answer is that pressure climbs early and stays up while nothing large is open, the next hour is better spent auditing login items and background agents than closing windows. Reading the menu bar row is the quickest way to start that list, and keeping it readable with a tool built for it makes the audit something that can be repeated rather than done once and forgotten.