When your VPS CPU spikes to 100%, the first symptom is usually a sluggish SSH connection, website timeouts, and even simple commands like ls can lag for several seconds. This situation is very common with VPS hosting, especially when running WordPress or high-traffic web applications.
The problem is that many administrators immediately think of upgrading their VPS the moment they see 100% CPU usage. In reality, there are many different underlying causes—ranging from heavy MySQL queries and misconfigured PHP-FPM to hidden malware. Understanding the root cause will help you fix the issue properly instead of throwing money out the window.
Checking the Current CPU Status
The first step is to see exactly where your VPS is bottlenecked. These three commands will give you a quick overview:
Checking the Load Average with uptime
uptime
Example Output :
12:34:56 up 5 days, 2:15, 2 users, load average: 3.45, 2.89, 1.67
Load average represents the average number of processes waiting for the CPU over the last 1, 5, and 15 minutes. If your VPS has 2 CPU cores and the load average is above 2.0, it is a clear sign of an overload. In the example above, a load average of 3.45 on a 2-core VPS means the CPU is heavily bottlenecked.
💡 Tip: Load average > number of CPU cores = VPS is overloaded, immediate action required
Viewing Real-Time Statistics with the top Command
top
Example Output:
top - 12:35:21 up 5 days, 2:15, 2 users, load average: 3.21, 2.95, 1.89
Tasks: 127 total, 4 running, 123 sleeping, 0 stopped, 0 zombie
%Cpu(s): 85.3 us, 12.1 sy, 0.0 ni, 2.1 id, 0.5 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 2048.0 total, 156.4 free, 1654.2 used, 237.4 buff/cache
MiB Swap: 1024.0 total, 890.2 free, 133.8 used. 231.6 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3429 mysql 20 0 1.2g 456m 12m S 67.3 22.9 8:45.67 mysqld
1847 www-data 20 0 456m 89m 8m R 18.7 4.5 2:34.12 php-fpm
1923 www-data 20 0 421m 76m 7m S 12.1 3.8 1:56.34 php-fpm
982 nginx 20 0 128m 24m 6m S 2.3 1.2 0:45.11 nginx
The %Cpu(s) line shows the CPU breakdown:
us (user): 85.3% – User-space processes (MySQL, PHP, Apache…)
sy (system): 12.1% – Kernel/system processes
id (idle): 2.1% – Idle CPU (the lower this is, the more alarming)
wa (wait): 0.5% – Waiting for disk I/O
st (steal): 0.0% – Steal time (CPU time “stolen” from your VPS by the physical host)
A Visual Interface with htop
htop
htop offers a much cleaner, color-coded interface:
Green: User processes (normal activity)
Red: System/kernel processes
Gray: Waiting for I/O (disk, network)
Cyan: Steal time (a sign that the VPS host is oversold)
Blue: Low priority processes
⚠️ Note: If you see a lot of red or cyan, it is a sign that you need to investigate further.
Distinguishing Between Different Types of CPU Load
Not all 100% CPU scenarios are created equal. By looking closely at the %Cpu(s) line in the top command, you can pinpoint the primary culprit:
High %us (>70%) – User-Space Applications
This is the most common scenario. The CPU is being heavily consumed by applications running in user-space, such as MySQL, PHP-FPM, Apache, Nginx, or Node.js.
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
6 0 0 512000 85532 890140 0 0 2 8 85 156 78 15 7 0 0
5 1 0 511800 85532 890144 0 0 0 4 92 189 82 12 6 0 0
Symptoms:
High r (6, 5): Multiple processes are actively waiting for CPU cycles.
High us + sy (78+15=93%, 82+12=94%): The CPU is working under extreme load.
Low id (7%, 6%): The CPU has virtually zero idle time to rest.
Low wa (0%): No disk or network I/O bottlenecks are present.
Solution: Optimize your applications, tune your database queries, or adjust service configurations.
High %sy (>30%) – System/Kernel Space
The CPU is being heavily consumed by the operating system kernel, usually due to heavy network I/O, excessive context switching, or driver-related issues.
Symptoms:
No single user-space process shows abnormally high CPU usage.
Massive spikes in network traffic (monitored via iotop or iftop).
High rate of context switches (monitored via vmstat).
Solution: Check network traffic, tune kernel parameters, or contact your VPS provider.
High %wa (>20%) – I/O Wait
The CPU is sitting idle while waiting for disk or network I/O operations to complete. This is not an actual CPU performance issue, but rather a storage bottleneck.
iotop -ao # View which processes are reading/writing the most to the disk
Example Output :
Total DISK READ: 125.67 M/s | Total DISK WRITE: 234.12 M/s
PID USER DISK READ DISK WRITE SWAPIN IO COMMAND
3429 mysql 89.23 M/s 156.78 M/s 0.00 % 67.23 % mysqld
2341 root 23.45 M/s 78.90 M/s 0.00 % 23.12 % rsync
ℹ️ If you see a high %wa, refer to the guide on dealing with high Disk I/O for specific troubleshooting steps.
High %st (>5%) – Steal Time
Your CPU cycles are being “stolen” by the physical host to serve other virtual machines. This is a telltale sign of an oversold provider or a “noisy neighbor” on the same hardware.
🚫 Warning: If steal time is above 10%, contact support immediately—this is an infrastructure-level issue.
Finding the Process Hogging the CPU
Once you understand the type of load, the next step is to pinpoint exactly which process is “eating” your CPU.
Using the ps Command to Sort by CPU Usage
ps aux --sort=-%cpu | head -15
Example Output :
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
mysql 3429 67.3 22.9 1234567 456789 ? Sl 10:23 8:45 /usr/sbin/mysqld
www-data 1847 18.7 4.5 456789 89012 ? S 09:15 2:34 php-fpm: pool www
www-data 1923 12.1 3.8 421345 76543 ? S 09:18 1:56 php-fpm: pool www
www-data 2156 8.9 3.2 398765 65432 ? S 09:45 1:23 php-fpm: pool www
root 2341 6.7 1.2 234567 23456 ? D 11:30 0:45 rsync -av /backup/
Reference :
https://haduymusic.com/server-administration/high-vps-cpu-usage-100-causes-and-fixes/
Top comments (0)