Disk Speed Matters More Than You Think

Disk speed is the specification nobody compares and the one most likely to be causing a stutter that memory and CPU upgrades did not fix.

It is invisible in the usual way: a game server spends most of its time doing nothing with the disk, and then periodically does something enormous with it, saving a world, loading a region, writing a backup, and everything stops while it happens.

Where a game server touches the disk

Saving. Every persistent-world game writes its state periodically. On Minecraft that is chunk data, on survival games it is the world and player inventories, and the write is large and bursty.

Loading. A player walking into unexplored terrain generates and writes chunks. A player walking into explored terrain reads them. On a large world with players spread out, this is close to continuous.

Logging. Small and constant, and only a problem when something has turned debug logging on.

Databases. Every plugin write, if there is a database. Databases for game servers covers when this becomes the dominant cost.

Backups. The largest single disk event most servers have, and the one most likely to be scheduled at exactly the wrong moment.

What a slow disk looks like

It does not look like slowness. It looks like intermittent freezing.

The signature is a hitch that recurs at intervals, every five minutes, every ten — while the server is otherwise fine. That interval usually matches an autosave. Players describe it as lag; the tick counter shows a spike rather than a sag.

The other signature is a freeze when somebody explores. One player walking into new terrain generates chunks, which is CPU work followed by disk writes, and on a slow disk the writes are what everyone feels.

This is frequently misdiagnosed as a memory problem, because the timing looks similar to a garbage collection pause. The way to tell them apart is whether the interval matches your autosave setting or your heap behaviour; RAM, heap and Java flags covers the memory version.

What matters in the specification

NVMe against SATA SSD is a real difference for this workload, and larger than the sequential-throughput numbers suggest. What game servers do is many small random operations, and that is where NVMe separates itself.

Spinning disks are still sold on cheap tiers and are unsuitable for any persistent-world game. If a provider is offering HDD storage at a low price, that price is the reason.

IOPS limits are the thing to ask about. Some providers cap operations per second on cheaper plans without mentioning it on the page, and a capped disk produces exactly the periodic freeze described above while every benchmark of raw throughput looks fine.

Shared storage on a virtualised host means your IO competes with other customers. On a quiet host this is fine; on a busy one your autosave lands whenever somebody else's does.

Choosing a game server host covers asking about this properly, and it is question three on that list for a reason.

Diagnosing it

Check whether the hitch matches your save interval. Look up what your autosave is set to and time the stutters. If they match, you have your answer in thirty seconds.

Watch IO wait. htop shows it, or iostat if it is installed. A server where the CPU is idle and IO wait is high during the freeze is disk-bound, not compute-bound.

Test the disk directly. fio or even dd gives you a number to compare against what you were sold. Random 4K performance is the relevant figure, not sequential throughput.

Check disk space. A disk near full behaves badly on most filesystems, and it is free to rule out. df -h.

Profiling a slow game server covers the general method; disk is the branch people reach last and should reach earlier when the pattern is periodic.

What to do about it

Move the save interval. Longer between saves means fewer stutters and more to lose if the server dies. On most games this is a straightforward trade and the default is not sacred.

Stagger anything scheduled. Backups, saves, mine resets and world regeneration should not coincide. Two large disk events at the same moment is a freeze rather than two hitches.

Put backups somewhere else. Writing a backup to the same disk the server is reading from is the most common self-inflicted version of this problem, and it is also not a backup in any meaningful sense. Game server backups covers off-machine properly.

Bound the world. An unlimited world grows without limit, and a larger world means more chunk reads from a colder cache. A world border plus pre-generation removes the whole category, why your Minecraft server lags covers this among the rest.

Prune what grows forever. Logs nobody rotates, backups nobody deletes, database tables nobody trims. All three end with a full disk, which produces failures that look like anything else. Reading game server logs covers rotation.

Then consider faster storage. After the above, because reducing the work is cheaper than buying capacity and frequently sufficient.

Where it sits in the buying order

For a server that feels wrong, the honest ordering is:

First, single-core clock speed, because it is what the tick loop runs on and what players feel every second rather than every five minutes. More cores will not fix your server.

Second, disk, because a periodic freeze is the second most common hardware-caused complaint and NVMe removes most of it.

Third, memory, and only enough. Buying more than the server uses does nothing.

Cores last, and only when running several things on one box.

That ordering surprises people because hosting pages advertise it almost exactly backwards.

How to tell whether disk is your problem

Three checks, in order, and most people can stop after the first.

Look at whether the slowness is periodic or continuous. Disk problems on game servers are almost always periodic, because the disk work is almost always a scheduled job: an autosave, a backup, a world write, a log rotation. Continuous slowness that scales with player count is a CPU problem wearing a disguise. Profiling a slow game server covers separating them properly.

Watch iostat -x 5 while the stutter happens. The column worth reading is utilisation, and the one worth reading next is the average wait. A device at high utilisation with rising wait times during your autosave is a confirmed answer. A device sitting near idle while players complain means the disk is not involved and you can stop looking at it.

Check whether the pause moves when you move the schedule. Shift the autosave by twenty minutes. If the complaint moves with it, you have found the cause without measuring anything.

The fixes, cheapest first

Reduce how often you write before you buy anything faster.

Autosave intervals on most game servers default low, because the default assumes a small world and few players. A Minecraft server saving every thirty seconds with a large loaded area is doing continuous disk work for a protection that saving every five minutes provides almost as well. The trade is how much progress a crash costs, and five minutes is usually acceptable where thirty seconds was never necessary.

Move backups off the game disk and off the peak hour. A backup that reads the whole world directory competes with the server writing to it. Running it at the daily low point costs nothing and removes an entire class of complaint. Game server backups covers doing it without a pause at all.

Turn down logging. Verbose logging on a busy server is a surprising amount of continuous small writes, and almost nobody reads the output. Reading game server logs covers keeping what is useful.

Prune what has accumulated. Old logs, old backups, orphaned world regions, a database table nobody has cleaned. A disk near full behaves worse than a disk half full on almost every filesystem, and the fix is free.

Then, and only then, buy faster storage.

What faster storage buys

Less than the marketing suggests, and it depends entirely on which number was your constraint.

Moving from a mechanical disk to any solid-state device is transformative, and if you are still on spinning storage for a game server this is the largest single improvement available to you.

Moving from SATA solid-state to NVMe is a smaller step than the throughput numbers imply. Game servers issue small scattered writes rather than large sequential ones, and the gap between the two on that workload is much narrower than on a benchmark. If your autosave stutter survived a move to NVMe, storage was not the problem.

Network storage is the case worth avoiding. Some hosts back their instances with remote volumes, and the latency floor on those is high enough to be visible in a game loop. This is not something you can tune away, and it is worth asking a host directly before committing. Choosing a game server host covers what to ask.

The check worth doing today

Time your autosave stutter, if you have one. Look up the interval, watch the tick counter, and see whether they match.

It takes two minutes, it costs nothing, and it either eliminates disk as a suspect or hands you the answer. Most owners with a periodic freeze have never done it and have instead spent money on memory.