Noisy neighbours and CPU steal on shared hosting

Your game server shares a physical machine with other servers, and sometimes people blame that for lag that is actually their own: here is how to tell the difference, what the panel graphs can and cannot show you, and what to send us if you think the machine is at fault.

6 min read · Updated Oct 21, 2026 · By GuavaHost Team

What sharing a machine actually means

A game server does not get a whole computer to itself. It runs in a container on a physical machine, called a node, alongside other customers' servers. Your RAM and your disk space are yours, carved out and guaranteed. CPU time is the part that is shared: the node has a fixed number of cores and the operating system hands slices of them out to whoever is asking.

Most of the time this is invisible, for a boring reason. Game servers are bursty. They spike when a player loads chunks, blows something up or logs in, and then go quiet. Those spikes almost never land at the same moment across every server on a node, so everyone gets the core time they need.

What makes it go wrong is a server that does not burst but sits flat out for hours, and that happens rarely enough that it is the wrong first explanation for your lag.

What CPU steal is

CPU steal is the time your server was ready to run but had to wait because the physical CPU was busy doing something else. It is measured as a percentage of time spent waiting rather than working.

A small amount of steal is normal on any shared machine and you will never feel it. Sustained high steal is not, and it produces a specific symptom: your server does hardly any work, uses hardly any memory, and is still slow. That mismatch is the tell. If your own numbers say you are busy, steal is not your problem.

What the panel graphs show, and what they do not

Your server's Overview tab has a Usage card with CPU, RAM and storage, and View history opens a chart over time. These are useful, but be clear about what they measure.

They show your container's CPU usage as a percentage of your plan's allowance, your memory use against your limit, and your disk use. All of it is your process, nobody else's.

They do not show how busy the node is overall, what other customers are doing, steal time, or anything about the network path to a player.

So the graphs can prove that you are the cause, but not that you are not. That asymmetry is why the next section exists. Your server's resource graphs covers reading them in detail.

First, rule yourself out

Nine times in ten the answer is in your own server, and it takes ten minutes to find out. Do this first.

1. Check TPS and MSPT. Run tps and mspt in the Console tab. If MSPT is above 50, your server cannot finish its ticks in time. Reading TPS and MSPT explains the numbers.
2. Compare process CPU against machine CPU. This is the useful one. On a server with spark, spark tps prints CPU usage for both the server process and the whole machine. If your process is near its ceiling, the work is yours. If your process is low and the machine's is high, something outside your container is busy.
3. Run a profile. spark profiler start --timeout 600 while the lag is happening. If the report names your plugins, your entities or chunk generation, you have your answer. Find what's causing lag with spark walks through reading it.
4. Check memory. Repeated long garbage collections look exactly like outside interference: the server freezes for a second with no obvious cause. Run spark gc to see the history.
5. Make sure it is not ping. If one player lags and the rest are fine, nothing on the machine is wrong.

Most Minecraft-style servers only use one core heavily, so a single expensive plugin or a huge mob farm can pin that core while your overall CPU figure looks modest. Why single-thread performance matters explains that trap, and it is the most common reason people reach for the noisy-neighbour explanation too early.

Signals that it really is the node

Taken together, these point outward rather than inward:

• MSPT is bad but your profile is flat. No plugin, entity type or task stands out; the time is spread thinly across everything, which is what waiting looks like in a profiler.
• Machine CPU is high while your process CPU is low.
• The slowness arrives and leaves at the same wall-clock times, with no matching change in your player count or activity.
• The server was fine for months with the same plugins, world and player count, and nothing on your side changed.
• It affects everything at once, including things that are usually instant: the console responding, files saving, a backup running.

One of these on its own means little. Three or four together is a real report worth sending.

What to send us

Our team is on Discord 24/7 and you can open a ticket from support. A good report gets a real answer on the first reply, and a vague one costs you a round trip. Include:

• Which server. Its name and address, so we know which node to look at.
• When. Specific times and dates, in UTC or with your timezone. "Yesterday evening" is hard to match against machine history; "19:40 to 20:10 UTC on the 18th" is easy.
• A spark profile link. Anyone with the link can open the report, so paste it straight in. Take it during the lag, not after.
• The spark tps or spark health output from the same window, showing process CPU against machine CPU.
• A console excerpt from around the worst moment.
• What you ruled out. Which plugins you removed, which settings you changed, what the profile said.

If a node genuinely is the problem, moving your server is the fix, so say so in your ticket. You can also move a server to a different region yourself from Change location on the Overview tab; see changing your server's region. That is usually about getting closer to your players, but it does put you on different hardware.

Things that do not help

• Raising watchdog or timeout values. This hides freezes instead of fixing them, and silences a crash report that would have named the cause.
• Restarting on a loop. If the cause is outside your container, a restart buys a few quiet minutes and loses your evidence.
• Buying more RAM for a CPU problem. They are different resources, and memory headroom does nothing for a pinned core.
• Blaming the disk. Every GuavaHost server runs on NVMe SSD storage, so disk speed is almost never the bottleneck.

Common questions

Is shared CPU the same as being oversold?

No. Sharing CPU time between bursty servers is normal and is how nearly all game hosting works, including the expensive kind. Overselling means packing so many servers onto a machine that their normal bursts collide, which is a capacity decision rather than a property of sharing.

Can I see how busy the node is from my panel?

Not directly. The usage card and its history chart measure your own container, so the closest you can get is comparing your process CPU with the machine CPU figure that spark reports. If that gap looks wrong, send it to us and we will look at the node from our side.

Would a dedicated machine fix this?

It removes the possibility entirely, since nothing else runs on the hardware, but it only helps if steal was really your problem. If a plugin is eating a whole core, it will eat a whole core on dedicated hardware too. Rule yourself out first, then ask us about the options.

How quickly can you tell whether a node is overloaded?

Much faster if you give us a specific time window, because we can see node-level history that your panel does not expose. The times and the spark output are what turn a guess into an answer.

Still stuck? Jump into our Discord at discord.gg/GuavaHost and the team will help you out.

• cpu
• shared hosting
• lag
• diagnostics
• performance

Still need help? Our team is online 24/7 to answer questions.

Contact support