Diagnosing CPU overload on a Linux game server

High CPU usage can cause slowdowns, disconnections and irregular response times on a Linux game server. On a VPS, a virtual machine or a dedicated server, the diagnosis must distinguish the processor, the memory, the SSD storage, the network and the hosting services. Before restarting or changing VPS plan at a cloud host, identify the process responsible and measure the effect of each correction.

Checking the real load

Connect over SSH with a root or administration account, then watch the load for several minutes. The uptime command shows the uptime and the load averages. These values represent an average of tasks waiting for processor time or for access to resources. They must be compared with the number of vCPUs and the real state of the virtual servers, rather than read as an isolated percentage.

uptime
nproc
mpstat -P ALL 1 5
free -h

With mpstat, look at the time spent in user mode, in system mode and waiting for input-output. A high load with a lot of waiting time is not treated as a pure CPU loop. Also check the available memory, the swap and the disk space. This distinction avoids changing the game configuration when the problem actually comes from the storage, a backup or a network service.

Identifying the responsible process

Use top or htop to sort processes by CPU usage. Note the name, the PID, the user and how the usage evolves over several refreshes. A single spike during a backup does not have the same cause as a process that stays at the top for the whole session.

top -o %CPU
ps -eo pid,ppid,user,%cpu,%mem,etime,cmd --sort=-%cpu | head -n 15

In a Pterodactyl environment or with several game servers, link the PID to the relevant service or container before any action. If you use a control panel, compare its metrics with the SSH measurement and your monitoring tool. Do not kill a process at random: first export its full command and check the owner of the service.

Distinguishing the game, a plugin and a service

If the game server process consumes the CPU, compare the time of the spike with restarts, player connections, a world generation, a backup or a scheduled task. If a plugin or a script appears separately, disable only one change at a time in a controlled environment so you can roll back.

For a service managed by systemd on Ubuntu, Debian or another Linux distribution, check its state and its logs. journalctl helps connect a load increase to a repeated error, a restart or a periodic task:

systemctl --type=service --state=running
journalctl --since "30 min ago" -p warning..alert
journalctl -u nom-du-service --since "30 min ago"
systemctl list-timers

Measuring before correcting

Keep your observations: time, load average, top processes, number of players, current event, available memory, disk activity and duration of the spike. This trace lets you compare two attempts and avoid a correction based on an impression. Also check the limits of the VPS, the virtual server or the physical server and the resources available in your hosting space before changing the game or operating system configuration.

Prudent actions consist of stopping a non-essential scheduled task, reducing an operation known to be costly, updating a component after a backup and limiting concurrent processes. Also check the firewall rules, the IP address and the network errors, without mistaking a bandwidth problem for CPU saturation. After each action, repeat the measurement. Increasing the restart frequency does not fix a root cause and can hide useful logs.

Avoiding false corrections

Do not add swap to solve CPU saturation: swap is mainly about memory and can increase waiting times if the server lacks RAM. Do not change the number of threads without knowing the software involved. Do not change several parameters at once, because you will no longer know which one had an effect.

If the load reappears at regular intervals, look for a scheduled task with systemctl list-timers and the crontab of the account concerned. If it appears together with a player action, examine the plugin, the script or the content generation triggered by that action. If it stays constant despite stopping the game server, check the other services, the administration panel and the system processes.

Knowing when to resize

Resizing is justified when the load stays high after identifying the processes, reducing the useless tasks and checking the configuration. Then compare the processor profile, the available memory, the input-output, the traffic, the storage space and the backups. Virtualization lets you scale a VPS or a virtual machine, while dedicated physical servers provide a machine to analyze separately. For a migration, back up the data and the configuration before changing plan. An SSD VPS can reduce storage-related waits, but it does not by itself fix a process that monopolizes the CPU.

Virtual machines and VPS hosting make it easier to scale a game server gradually. Monitoring must nevertheless stay active after a resource change. Compare the metrics before and after migration, especially the CPU, the memory, the disk and the network. For a complex configuration or a persistent incident, gather the logs and contact your host's technical support. A high-availability and redundancy strategy is designed separately from the CPU diagnosis. Read our information on the Linux VPS, the dedicated servers and the trade-off between a dedicated server and a VPS.

To continue your diagnosis, also read our guide on Docker on a VPS, the first security settings of a dedicated server and the method to diagnose an unreachable VPS. These checks cover different causes and must stay separate in your analysis.