Why your VM has no swap
Swap lets a machine pretend it has more memory than it does. On enterprise flash that pretense costs storage wear and a latency cliff, so we size the RAM instead.
In this article 5 sections
- RAM answers in about 100 nanoseconds. Fast flash answers in about 100 microseconds. A workload that falls into swap runs on memory roughly a thousand times slower.
- Swapping converts a RAM shortfall into storage wear and a latency cliff. The workload fails slower and more confusingly instead of failing clearly.
- We size the RAM instead. The Sizing Desk asks for your real free -m output before it proposes anything.
The virtual machines we build ship without swap. When one runs out of memory, the failure is immediate and visible, and the fix is a conversation about RAM. On a spec sheet that reads like an omission, so here is the reasoning in full. None of it depends on our hardware; you can apply the argument to any VM you run anywhere.
Swap exists to let a machine run past its physical memory
Swap is the kernel's overflow valve. When physical memory runs short, it moves the pages it judges coldest out to disk and hands the freed RAM to whoever is asking. The machine gets to report more memory than the silicon holds, every allocation gets to succeed, and the truth arrives later, as latency, whenever a process touches a page that turned out to live on disk after all.
That trade made sense when it was invented. RAM was scarce and expensive, machines were shared by many jobs, and a batch job that crawled overnight beat a batch job that died. Every part of that context has since inverted: RAM is the cheapest it has ever been per gigabyte, the machine is yours alone, and the workloads are interactive services where a tenfold latency excursion is indistinguishable from an outage. The overflow valve stayed in the defaults anyway, because defaults outlive their reasons.
Falling out of RAM costs you three orders of magnitude
The case against swap is arithmetic before it is philosophy. Memory and storage sit on different floors of the latency building, and the staircase between them is long.
- CPU CACHE
- about a nanosecond
- RAM
- about 100 nanoseconds
- FAST FLASH
- about 100 microseconds, a thousand times slower than RAM
- A PAGE FAULT INTO SWAP
- the full storage round trip, plus queuing, on the hottest path your workload has
The exact figures vary by hardware; the gaps between the floors do not. Under real memory pressure the machine takes that staircase continuously: the kernel evicts pages, the workload faults them straight back in, and the CPU spends its cycles waiting on storage. Load average climbs while useful throughput collapses.
~0.1 to 1 ms
100 ns
~10,000×
Swap burns enterprise flash to hide a sizing mistake
On spinning disks, swap was merely slow. On flash it is also corrosive. Swap traffic is the worst pattern you can feed flash: a continuous stream of small random writes that exist for no reason except that the machine is short on RAM. Every one of those writes ages a cell to preserve an illusion.
And the workload gets nothing back for the wear. It limps at storage pace until the pressure ends or someone intervenes. The array underneath your VM here is HPE 3PAR all-flash, and its job is serving your data at speed. Spending its write endurance as pretend memory is a bad trade at any price, which is why we would rather have the sizing conversation up front than paper over it with paging.
Without swap, memory exhaustion produces a log line instead of a mystery
The strongest argument is diagnostic, and anyone who has chased a slow week through a monitoring stack already knows it. With swap, running out of memory looks like everything except running out of memory. Latency rises across every service at once, no error appears in any log, and the dashboards point everywhere the wait is felt, which is usually the database and the storage. Teams lose days to that chase, and swap manufactures it on a single machine, routinely, by design.
- Latency climbs across every service at once, with no error in any log
- Dashboards blame the database, then the storage, then the network
- The array absorbs a stream of small random writes whose only job is hiding the shortfall
- The diagnosis arrives days later, after someone correlates the graphs
- The kernel kills the largest offender and names it in the log
- The failure has a timestamp, a process name, and a memory total
- The array spends its writes on real data
- The fix is a resize conversation the same day
A memory graph on a swapless machine tells the truth all the way to the edge.
We size the RAM honestly and ask for your real free -m
The honest fix for a memory shortfall has been the same since paging was invented: more RAM, or a smaller working set. So that is where we spend the effort. The Sizing Desk asks for the actual free -m output from your current machine before they propose anything, because the available column of that command settles arguments that adjectives never will, and the same reading that removes the need for swap usually shrinks the quote too.
The full method, with worked examples of every number we ask for, is in how to size a server. On owned hardware the headroom already sits in the box you paid for, so provisioning it costs nothing extra at your peak, which removes the last economic excuse for treating storage as overflow RAM.
Straight answers
Doesn't the kernel need some swap to run well?+
The kernel can use swap to evict genuinely cold pages and hand the reclaimed RAM to the disk cache, and on a chronically tight machine that helps at the margin. The margin is the problem. It buys a few percent of effective memory while hiding whether the machine is big enough at all, and it blurs every memory graph you will later depend on. On a right-sized machine the cold-page win rounds to nothing, and the diagnostic clarity of a hard memory boundary is worth far more at 3am.
How do I find out how much RAM I actually use?+
Run free -m across a real peak and read the available column. The full method, with worked examples of every number, is in our sizing post, how to size a server. If that column says you are genuinely tight, the answer is more RAM, and we will say so.
No swap is a small decision downstream of bigger ones: size machines to real numbers instead of invoices, and put serious hardware underneath them so the numbers hold on a bad night. The RAM conversation is cheaper than the mystery it prevents.
Size the RAM honestly
The Sizing Desk starts from your machine's actual numbers and proposes a build from our real building blocks. When your numbers say less, it sizes you down.
Open the Sizing DeskYou’ve reached the end.
Put the reading to work
What are
you running?
Tell us about the workload, traffic and recovery requirements. Start with the server builder, or talk through the details with an engineer.
Written by the engineers who build and run the infrastructure it describes.Talk to an engineer