When to upgrade your hosting plan, and when not to

Upgrading is the easiest thing to do and therefore the first thing suggested, including by hosts who benefit from it. Some problems are genuinely a size problem. Rather more of them are a configuration problem wearing a size problem's clothes, and the only way to tell the difference is to look at which resource is actually at its limit rather than at which one is easiest to buy.

The honest summary: upgrade when a resource is exhausted at idle rather than at peak, when the kernel has killed something, when the disk is full, or when you are deliberately adding load. Do not upgrade because the server feels slow, because the memory graph looks high, or because somebody in your Discord said so. This post is the diagnostic in between - the exact log lines, counters and graph shapes that separate one from the other.

The four signals that are genuinely a size problem#

Each of these is a reason to move up. Together they cover almost every case where more resources is the right answer.

• The memory floor is high, not just the peak. The floor is the lowest point the memory line touches between spikes, measured over a day rather than an hour. When the floor sits above roughly 80 per cent of the limit, there is no headroom left for a garbage collection cycle, a backup, or twelve people logging in at once. A peak that touches the ceiling and comes straight back down is normal.
• The kernel has killed something. An out-of-memory stop, an allocation failure in the log, or a process that vanished without an error of its own. This is not an opinion about whether the plan is big enough; it is the operating system telling you it is not.
• Disk is full or nearly full. No amount of tuning creates space. You can delete things, which is often the correct answer, but once the real working set exceeds the plan it is a size problem and nothing else.
• You are deliberately adding load. More players, a bigger world, a modpack, a second service, a launch. Upgrading before the load arrives is the only time buying capacity speculatively is sensible, because you know the number is going up.

Everything else deserves ten minutes of diagnosis first.

Read the floor, not the peak#

The most common misreading in hosting is a memory graph near the top of its range. For anything running on the JVM that is not a warning, it is the design: the runtime takes the heap it was given and uses it, collecting garbage when it approaches the limit rather than continuously. A Minecraft server sitting flat at ninety per cent of its heap can be perfectly healthy.

What tells you something is the shape over time:

Take the reading at the quietest hour you have. A server with nobody on it should be well clear of its limit; if it is not, peak is going to hurt. And take it over at least twenty-four hours, because a restart resets everything and makes any plan look sufficient for the first two hours. Reading a server load graph goes through the shapes in more detail.

One trap specific to containers: free -m run inside a container reports the host machine's memory, not your limit, so it will cheerfully tell you there are 60 GB free while your process is about to be stopped. Read the cgroup instead:

$ cat /sys/fs/cgroup/memory.current   # bytes in use$ cat /sys/fs/cgroup/memory.max       # your limit$ cat /sys/fs/cgroup/memory.events    # includes an oom_kill counter

On older systems using cgroup v1 the equivalents are memory.usage_in_bytes, memory.limit_in_bytes and memory.failcnt. On a panel, the memory graph already shows usage against the limit, which is the same information without the arithmetic.

Proving it was memory#

If a server died, the evidence exists. Find it before you buy anything, because "it crashed" and "it ran out of memory" are different problems with different fixes.

Exit code 137. In a container this is 128 plus signal 9, so the process was killed rather than exiting. Almost always the memory limit. Exit code 143 is 128 plus signal 15, a clean SIGTERM, which is a normal stop or restart and not an error at all.

A kernel message. On a machine you control, dmesg -T | grep -i -E "oom|killed process" produces something like:

Memory cgroup out of memory: Killed process 8123 (java)total-vm:9812344kB, anon-rss:4194304kB, file-rss:0kB

That line names the process and the memory it held when it died. Swap and the OOM killer explains how the kernel chooses its victim.

A runtime error rather than a kill. These mean the process hit its own ceiling before the container's:

java.lang.OutOfMemoryError: Java heap spaceFATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memoryMemoryError

The distinction matters, and it is the single most common reason people buy a plan that does not fix anything. A Java server with -Xmx4G will throw a heap error on a 12 GB plan, because the flag, not the plan, is the limit. A Node process has its own old-space ceiling set independently of the container, which is the subject of why your Node app dies at 2 GB on a 4 GB plan. Check the flag before the tier.

The reverse trap is just as common on the JVM. Heap is not the whole process: metaspace, the code cache, thread stacks and direct buffers sit outside -Xmx and add several hundred megabytes. Setting -Xmx equal to the container limit guarantees an out-of-memory stop at some point, because the process needs more than its heap. Leave 20-25 per cent of the plan outside the heap on a Minecraft server.

One more thing worth knowing before you spend an evening on this: a server that restarts repeatedly gets noticed. A watcher polls every couple of minutes for uptime that went backwards or a server that went offline, and restarts you asked for are not counted. Three unexpected restarts in an hour puts a warning on the server page and opens a ticket automatically; six leads to suspension. If your server is in that state, the upgrade decision is not the urgent one.

Proving it was CPU: throttling is not shortage#

A stuttering server with calm memory is a CPU problem, and buying memory will change nothing at all. The distinction is easy to make and almost nobody makes it.

CPU on a container plan is a hard throttle to the share you bought. When you exceed it, the kernel does not slow you down gradually; it stops scheduling your process for the rest of the period and resumes in the next one. That is why a CPU-limited server stutters in a regular rhythm rather than degrading smoothly. The counter is readable:

$ cat /sys/fs/cgroup/cpu.statnr_periods 184320nr_throttled 41277throttled_usec 892134000

nr_throttled climbing against nr_periods is the proof. On cgroup v1 the file is in /sys/fs/cgroup/cpu/cpu.stat and the field is throttled_time in nanoseconds. On a panel, the CPU graph pinned flat at your share is the same signal without the file.

For a game server, the game's own measurement is usually clearer. On Paper or Spigot, /tps reports ticks per second against a target of 20, and MSPT reports how long a tick actually took against a budget of 50 ms. A server at 18 TPS with 55 ms ticks and 40 per cent memory usage is unambiguous: the plan has plenty of memory and not enough clock. Newer Paper builds have replaced timings with spark, so check which your build has and profile with /spark profiler if it is there. Why TPS drops and reading a spark report take it from there.

The uncomfortable part: a bigger tier usually buys you more vCPU share, not a faster core. Most game servers are limited by single-thread performance, so going from 1.5 to 2.5 vCPU helps a server that was being throttled and does very little for a server whose main tick thread is simply doing too much work. Find out which one you have before paying. CPU or RAM is thirty seconds of diagnosis and saves a lot of money.

A server sitting at 100 per cent CPU is slow, not broken, and is never suspended for it.

Disk is the one you cannot tune away#

Disk pressure is the least interesting and most abrupt failure in hosting. A full disk stops a database writing, corrupts a world save mid-write, and prevents a log from rotating, all at once and without warning.

$ df -h /$ du -sh /* 2>/dev/null | sort -h | tail -20$ du -sh ./* | sort -h | tail -20

What actually fills a plan, in rough order of frequency:

• Logs that never rotate. A chatty server writing debug output can produce gigabytes a week. On systemd machines, journalctl --disk-usage then journalctl --vacuum-time=7d.
• Backups stored beside the thing they protect. A game's built-in backup folder is not a backup; it is a second copy on the same disk, and it grows forever. Keep real copies off the machine - backups that actually restore is about the half of this people skip.
• Old worlds, old maps, old modpacks. Nobody deletes the world from the last season.
• Build artefacts. node_modules from three deploys ago, a package manager cache, a Cargo target directory, a Docker image nobody prunes.
• Uploads. User-submitted images on a web application, at full resolution, forever.

Clean up first. Most full disks are 70 per cent rubbish, and deleting rubbish is free. If the real working set genuinely exceeds the plan, that is a size problem and you should move. It is also worth knowing that the tier does not change the kind of storage: NVMe is on every plan, so upgrading buys you space rather than speed. What NVMe actually changes is clear about which operations that affects.

Three symptoms that look like a size problem and are not#

Periodic stutter on a regular rhythm. A freeze every few minutes, at a predictable interval, is a save, an autosave or a backup - a disk and pause problem, not a shortage. Check the interval against your world save setting or your scheduled tasks before doing anything else. On a game server, lengthening the interval makes the freezes rarer and the potential loss larger; shortening it makes each freeze smaller. Neither is fixed by memory.

Low tick rate with calm memory. Covered above, and worth repeating because it is the single most expensive misdiagnosis in game hosting. A bigger memory tier does nothing for a CPU-bound tick loop. If the graph shows memory at 50 per cent and the server is at 14 TPS, memory is not the problem in any sense.

One player has problems and nobody else does. That is their connection or the route to it, and no plan changes either. Have them run an mtr to the server address and look for loss that starts at a hop and persists to the end. Latency, jitter and packet loss is the post to send them. Related: everything is hosted in one location, so upgrading does not move the server closer to anybody.

A fourth honourable mention: a server that feels slower after other people's busy hour started. That is contention, not your allocation, and it is a different conversation entirely - shared CPU and noisy neighbours is about what a share actually guarantees and how to tell the two apart.

Try these before you pay#

In order of effort against effect. For a game server:

1. Reduce view and simulation distance. On Minecraft, view-distance and simulation-distance in server.properties both default to 10. Dropping simulation distance to 6 cuts the per-tick work dramatically and is barely noticeable to players. This is the highest-value single change available.
2. Count your plugins and mods. Twenty plugins is twenty things running every tick. Remove the ones nobody has used since March, and profile the rest rather than guessing. Paper optimisation covers the configuration files that matter.
3. Check the entity count. Mob farms, item stacks on the ground and framed items are a common cause of a server that got slow without anybody changing anything.
4. Fix the memory flags rather than the plan. An -Xmx set too low throws heap errors on any tier; set too high it guarantees a container stop. How much RAM a Minecraft server needs has sensible numbers by player count and modpack.
5. Restart on a schedule. Memory that climbs for days on a long-running server is often normal accumulation rather than a leak, and a weekly restart at 5am keeps it flat for free.

For an application:

1. Cache the responses that do not depend on the user. Usually the largest single win, and free.
2. Find the slow query. One missing index routinely accounts for most of a database's CPU.
3. Bound every collection your code owns. A cache without eviction is a leak with a schedule.
4. Set the heap or worker count deliberately rather than inheriting a default sized for a laptop.

If you did all of that and the resource is still at its limit, you have a size problem, and now you know which resource to buy.

Choosing the next tier, and what it will not change#

Pick the tier by the floor, not the peak. Take the idle memory figure, add the peak-to-floor gap you observed, add 25 per cent, and buy the tier above that number. Doubling because the numbers look nicer is how people end up paying for 8 GB to run something that needed 3.

Be clear about what changing tier does and does not do:

• It does change the memory, disk and CPU-share limits on the server you already have. Changing plan does not rebuild the server, so the world, the files, the database slot and the domain stay exactly where they are.
• It does not change the storage class, because NVMe is on every plan; the location, because there is one; the single-thread performance of the core your tick loop runs on; the network path between a player and the machine; or a configuration mistake.
• It does not fix a leak. A process whose memory grows without bound reaches a bigger ceiling more slowly. That is worth something on a Friday night and nothing at all in the long run.

Give any upgrade a fair test. Watch for a full day at the same load, look at the same floor you measured before, and be willing to conclude it did not help - which is information, and points at configuration. Longer billing terms of three, six and twelve months are cheaper per month, so it is worth settling on the right tier before committing to one of them.

Set up something that tells you before the next ceiling arrives rather than after. A memory alert at 85 per cent of the floor and a disk alert at 80 per cent will give you days of warning instead of an outage. Monitoring that tells you something is about doing that without building a second job for yourself.

FAQ#

How do I know whether I need more RAM or more CPU?

Look at both graphs during a bad moment. Memory at the ceiling with the process being killed is memory. CPU pinned at your share with memory comfortable is CPU. If a game reports low TPS or high MSPT while memory is calm, it is CPU, and no memory tier will help.

My memory graph is always near the top. Is that bad?

Usually not. Java and several other runtimes take the heap they were given and use it, so a high, sawtooth-shaped line is healthy. What matters is the floor between spikes and whether the sawtooth returns to the same level. A floor that creeps upwards over days is the thing to investigate.

Does upgrading restart my server?

Changing plan does not rebuild the server: the files, world, database slot and settings stay where they are. Expect the process itself to come back up on the new limits, so pick a quiet moment in the same way you would for any restart.

Can I go back down if the upgrade did not help?

Tiers are not one-way, but check disk first, because it is the one dimension that does not shrink gracefully: a smaller tier has to be large enough for what you are actually storing. Clear out old worlds and stale backups before moving, and ask through a ticket if you are not sure.

Why did my server restart by itself instead of just slowing down?

Because at the memory limit the container is stopped and restarted clean rather than left to swap. It looks like a crash and it is not. Check for exit code 137 and an out-of-memory line, and if you find one, the plan or the heap flag is genuinely too small.

Should I upgrade before a big event or launch?

Yes, this is the one case where buying ahead is sensible, because you know the load is going up rather than guessing. Move up a few days early, watch the graphs under real use, and decide afterwards whether to stay.