"My server is overloaded — CPU sustained at 127%"
You opened the diagnostic helper, asked why your server feels laggy, and the panel told you CPU is sustained above 100%. A reasonable first thought is "computers don't go above 100%, this is a glitch." It is not a glitch. This page explains exactly what that number is, when an upgrade actually helps, and when it doesn't.
Why the number can be over 100
Linux measures process CPU time across all cores. A single core running flat-out for one second is "100% of one core." If your game server spawns three threads and all three are busy for one second, the process has consumed three core-seconds in one wall-clock second, which the kernel reports as 300%.
Game servers are multi-threaded by default. Palworld runs roughly 4 to 6 worker threads in addition to the main game thread. Valheim, ARK, Conan, Satisfactory all spawn at least a network thread and a save-IO thread. So sustained CPU values between 100 and 300 are normal for a busy multiplayer session, not a sign that something is wrong.
The number you see is the per-process total. The diagnostic helper flags it as "sustained" when the 5-minute rolling average crosses 90% of one core. That threshold is deliberately low so the helper catches a real problem early; it does not mean the server is in trouble at 91%.
When the high number actually hurts
Two things matter, in order:
- Whether the game's main thread is saturated.
- Whether your plan tier hits the CPU shares cap.
Most games have a single main thread that runs the simulation tick (world update, AI, physics). If that one thread is at 100%, the tick rate drops and players see lag, regardless of how many other cores are sitting idle. Helper threads at 300% combined does not save you if the simulation thread is choked.
Plans on a shared node carry a CPU-shares limit enforced by cgroups. Hit that ceiling and the kernel throttles your process. In the panel you will see "cpu_sustained" stuck at exactly the limit and the in-game world tick stuttering.
What helps and what does not
| Symptom | Diagnosis | Fix |
|---|---|---|
| Pal / Conan / ARK feel laggy, CPU 200%+ | Multi-threaded game, helper threads busy | Plan upgrade helps. Each tier adds CPU shares; helpers get room. |
| Lag in a single-threaded sim game (older PZ MP, modded MC), CPU around 100% | Main thread is the bottleneck | Plan upgrade barely helps; faster single-thread node helps more. Open a support ticket; we can migrate to a node with higher per-core clock. |
| CPU spikes to 130% only at autosave, then drops | I/O burst, not CPU sustained | No upgrade needed. Reduce autosave frequency if possible. |
| CPU climbs from normal to ceiling over an hour | Memory leak / runaway entity count | Restart-on-schedule reduces it. Investigate which mod or in-game system is responsible. |
| Lag at peak hours, fine off-peak | Noisy neighbour on the shared node | Node migration. Open a support ticket. |
Reading the in-panel graph
The Resource Usage card on the Basic Control tab shows a rolling graph of CPU and RAM. What to look for:
- Flat ceiling for several minutes: you are CPU-bound. Plan or node change.
- Saw-tooth pattern, regular interval: autosave or world-tick batch work. Usually harmless.
- Slow upward drift over an hour: a leak. Restart fixes for now; the underlying mod or setting needs attention.
- Random spikes only when a particular player connects: that player's actions (large base, factory build, AI swarm) trigger heavy work. Check what they are doing in-game.
What to do right now
If the panel just told you the server is overloaded, here is the short ordered list:
- Open the in-game world and look around. Is there an obvious culprit (huge factory, massive base, AI swarm, fire spreading)? Removing it usually drops the CPU number immediately.
- Restart the server. Many leaks reset to normal after a restart.
- If the load comes back within an hour, take note of how many players were online and what they were doing. That is the data point a plan upgrade is based on.
- Open a support ticket if the load stays high regardless of activity, with the server in the panel link. We can read the live process tree and tell you whether it is a game-thread issue, an I/O issue, or a noisy-neighbour issue.
Game-specific notes
Palworld
Pal benefits visibly from a plan upgrade up to 16 players. Above that, the game starts hitting the single-thread ceiling regardless of tier. Reduce PalCaptureRate and BaseCampWorkerMaxNum in PalWorldSettings.ini to bring per-tick cost down.
Single-thread-bound titles (Project Zomboid B41 MP, vanilla Minecraft)
Plan upgrades give you marginal headroom. What helps more is a node with higher single-thread clock. Ask support if a migration is possible.
Windrose, ARK, modded Valheim
RAM is often the real bottleneck before CPU. Watch the RAM graph too; 95%+ sustained for a few minutes is the support helper's other red flag and means you are paging.
Need more headroom? See plan tiers. Each tier doubles CPU shares and RAM; upgrades are one click and take effect on the next restart.