Knowledge base
How much server do you actually need
Most specifications are decided by anxiety rather than measurement, which is how people end up with 128 GB of memory and a disk that cannot keep up.
Measure what you have now
Twenty minutes with these gives you a better specification than an hour of guessing:
- CPU —
topat your busiest hour. Note whether one core is pinned or all of them are. That difference decides between a fast processor and a many-core one; see choosing a CPU. - Memory —
free -h, and look at available, not free. If available never drops below half, you do not need more. - Disk —
iostat -x 2. The number that matters is IOPS and await, not capacity. A database that waits on disk will not be helped by more terabytes. - Network — your monthly transfer and your peak rate. These answer different questions: transfer decides metered versus unmetered, peak decides port speed.
Rules of thumb that survive contact with reality
- Memory
- Size it to hold your working set plus room for the filesystem cache. For a database, the single most effective upgrade is usually enough memory to hold the hot part of the data; it turns disk reads into memory reads.
- Cores
- Count your concurrent units of work — worker processes, virtual machines, game instances — and leave a quarter spare. Cores you never use cost money every month.
- Storage
- Capacity for what you store, IOPS for how you store it. Mixed workloads want NVMe for the active data and spinning disks for the bulk. See SAS, SATA and NVMe.
- Port speed
- Peak rate, not average. A site that averages 200 Mbit but peaks at 2 Gbit during a release needs the headroom, or it falls over at precisely the wrong moment.
- Redundancy
- Decide now whether a disk failure may cause downtime. Mirrored disks cost half your capacity and save a rebuild at three in the morning.
Where people get it wrong
- Buying cores to fix a disk problem. High load with high
%wameans storage, not processor. - Sizing for the peak of the peak. One annual event does not justify twelve months of idle hardware; it justifies a plan for that week.
- Forgetting the operating system. Leave several gigabytes of memory and a healthy slice of disk for the system, logs and backups.
- Ignoring growth. Memory and disk are easy to add later; the processor and the motherboard are not. Choose the platform with room, then fill it over time.
Just describe the workload
We build to order, so you never have to pick part numbers. Tell us what the machine runs, how many users or jobs at once, how much data, and what would hurt most if it were slow. You get a quote that fits, and an honest word if what you asked for is unbalanced — which, with the figures above in hand, it rarely is.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base