How to size a server (most people need less than they think)
Cloud bills train you to size to your last invoice instead of your real consumption. The honest method lands smaller, and our tool proves it by trying to sell you less.
In this article 5 sections
- Your invoice is not your workload. You size to what you were billed, not what you actually burn.
- Three commands humble the invoice: free -m, df -h, and CPU steal over a real peak.
- On owned hardware, burst headroom is already in the box, so you size to real consumption plus honest headroom, not fear.
- Our sizing tool will propose smaller when your numbers say so. Right-sized customers stay.
Nobody arrives asking for a smaller machine. They arrive with a cloud bill and a mental picture of how big the workload must be, because the bill has been telling them a big number every month for years. The number is real. The size it implies almost never is.
Your invoice is not your workload
A metered bill measures what you were allocated and charged for, not what your processes touched. Over time you stop sizing to the workload and start sizing to the invoice, because the invoice is the only number in front of you. Most workloads that reach us use a fraction of what they are paying for.
So before we quote anything, we ask you to go look. Not at the bill. At the box.
The three commands that humble the invoice
free -m: are you actually RAM-bound
Memory is the resource people most often overbuy, because running out of it feels catastrophic. Run this on your current box and read the available column, not used. Cache is not consumption.
$ free -m
total used free shared buff/cache available
Mem: 64157 11238 1002 418 51917 52104Sixty-four gigabytes provisioned. Eleven in use. Fifty-two available, most of it sitting as reclaimable cache. This is a machine that thinks it is a 64 GB workload and is really a 16 GB one with a healthy disk cache.
df -h: how full is "full"
The other reflex buy is storage. Ask the disk what it holds rather than what it was sold as.
$ df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/nvme0n1p2 1.8T 240G 1.5T 14% /Two terabytes provisioned, fourteen percent used. That is not a storage problem, that is a storage habit. The number you need is the used figure plus a realistic growth curve, not the size of the last box someone bought.
CPU load and steal over a real peak
Sample your CPU across an actual busy window, not an idle Tuesday afternoon. On a shared cloud instance, watch the %steal column: that is time your workload wanted a core and the hypervisor gave it to a neighbor.
$ mpstat 1 3
CPU %usr %sys %iowait %steal %idle
all 22.10 3.40 0.80 6.20 67.50Sixty-seven percent idle at peak, and 6.2 percent of the time lost to steal on top of that. On bare metal that steal column reads 0.00, every day, because your cores are your cores. Some of the compute you think you need is not workload at all.
If you do not know them, we pull them with you on the call in about fifteen minutes.
Headroom is not a bigger box
The usual objection is: but I need room to spike. You do, and you already have it. On owned hardware, burst headroom is already there, because the empty capacity is in the machine you have. Nobody meters your peak. That means you size to real consumption plus honest headroom, and the headroom is free rather than a reason to buy the next size up.
On a meter, fear of the spike is rational, because the spike has a price tag. Delete the meter and the fear stops being a line item. You can size to what you burn.
Let the tool try to sell you less
Seven questions, no account. It proposes a real build at a real price, and it will size you down if your numbers say so.
Open the Sizing DeskWhy our tool argues you down
Our Sizing Desk down-sells on purpose. Feed it a heavy-sounding workload paired with honest usage answers and it will stamp the proposal WE SIZED YOU DOWN and quote the Reference Build anyway. The message it prints is deliberate: workloads like yours usually arrive shopping for a bigger machine, your usage answers say the Reference Build already carries more headroom than you described, so that is what we quoted.
This is not modesty. It is retention math. A right-sized customer runs comfortably and stays for years, and the simplest way to keep a customer is to not oversell in the first place.
A retail repair chain runs its ERP on one of these machines. Right-sized, uneventful, boring in the way infrastructure should be.
When you genuinely need more
Sometimes the numbers say go bigger, and then we do. The signals are real, not imagined: your available memory actually runs thin at peak, your disk is genuinely filling, your %idle is low when it matters. We build large single machines, up to four sockets, whatever the job earns.
Downtime is not an option
If downtime is unacceptable, the honest answer is a second node with failover, and the call prices both sides straight.
Past the ceiling, a human takes over
Beyond a single big build, the wizard escalates the design to an engineer.
Straight answers
What if I don't know my numbers?+
Then we find them together. We pull your real usage with you on the call, it takes about fifteen minutes, and it usually humbles the invoice. Not knowing is normal. Guessing big to be safe is the expensive mistake.
Will you refuse to sell me a big box?+
No. If your real numbers say big, we build big: one large machine, or a designed cluster past that. We just will not sell you big to hit a number. The tool argues you down first, then sizes up when the workload earns it.
What if I undershoot?+
Growing is a call, not a migration. Because burst headroom is already in the box, a right-sized build absorbs more than you would expect before you need more hardware. When you do, upgrading is a phone call, not a rebuild.
Pull your three numbers, then let the tool try to sell you less. If it sizes you down, that is not a trick. That is the whole method working.
You’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