GUIDETroubleshooting

"High CPU Usage — Diagnosis & Fix"

8 min read

High CPU usage on your VPS can cause slow response times, unresponsive applications, timeouts, and a poor experience for your users. The good news is that identifying the cause is usually straightforward, and most cases can be resolved without rebooting or upgrading your server.

This guide walks you through diagnosing high CPU usage, identifying the offending processes, and applying fixes for the most common causes.

Step 1 — Check Current CPU Usage

Connect to your server via SSH or the web console in your Data Mammoth dashboard. Then run one of the following commands to see real-time CPU usage.

Using `top`

top

The top command shows a real-time, updating view of all processes sorted by resource usage. Key information to look at:

%CPU column — Shows what percentage of a single CPU core each process uses. A process showing 100% is using one full core. On a 4-core server, total CPU capacity is 400%.
load average — Displayed at the top. The three numbers represent the 1-minute, 5-minute, and 15-minute load averages. As a rule of thumb, if the load average exceeds the number of vCPUs your server has, the server is overloaded.
%Cpu(s) line — Shows overall CPU breakdown: us (user processes), sy (system/kernel), ni (nice), id (idle), wa (I/O wait).

Press q to exit top.

Using `htop` (Recommended)

htop

htop provides a more user-friendly, color-coded view of the same information. If it is not installed:

# Ubuntu / Debian
apt install htop -y
AlmaLinux / Rocky / CentOS
dnf install htop -y

htop shows individual CPU core usage as bar graphs at the top, making it easy to see if the load is distributed across cores or concentrated on one.

Quick Snapshot (Non-Interactive)

For a quick, non-interactive snapshot of the top CPU consumers:

ps aux --sort=-%cpu | head -15

This lists the 15 processes using the most CPU, sorted from highest to lowest.

Step 2 — Identify the Culprit

Once you can see which processes are consuming CPU, identify what they are and whether the usage is expected.

Common High-CPU Processes and What They Mean

Process	Likely Cause	Normal?
`apache2` / `httpd`	High web traffic or misconfigured Apache	Often normal under load
`nginx`	High web traffic (less common to spike)	Usually indicates very high traffic
`php-fpm` / `php-cgi`	PHP script execution (WordPress, etc.)	Common with heavy traffic or bad plugins
`mysql` / `mysqld` / `mariadbd`	Database queries	May indicate slow queries or missing indexes
`postgres`	PostgreSQL database queries	Same as MySQL — check for slow queries
`node` / `python` / `java`	Application process	Depends on the application
`cron`	Scheduled tasks	Check what cron jobs are running
`gzip` / `tar` / `rsync`	Compression or backup operation	Expected during backup windows
Unknown process names	Potential malware or cryptocurrency miner	Investigate immediately

Investigating an Unknown Process

If you see a process you do not recognize consuming high CPU, investigate it:

# Find the full command and path of the process
ps aux | grep [PID]
Check where the binary is located
ls -la /proc/[PID]/exe
Check when the process started
ps -p [PID] -o lstart
Check what files the process has open
ls -la /proc/[PID]/fd/ | head -20

Replace [PID] with the actual process ID from top or htop.

If the process is unfamiliar and suspicious (random characters in the name, running from /tmp or /dev/shm), your server may be compromised. Kill the process immediately and investigate further:

kill -9 [PID]

Change all passwords, update the system, and consider reinstalling the OS from the dashboard. Contact support if you need assistance.

Step 3 — Apply Fixes for Common Causes

Web Server Overload (Apache/Nginx + PHP)

Symptoms: Multiple apache2 or php-fpm processes consuming high CPU.

Fixes:

Check traffic levels. Your site may be experiencing a legitimate traffic spike. Review access logs:

tail -100 /var/log/nginx/access.log
tail -100 /var/log/apache2/access.log

Look for bot traffic. Aggressive bots and crawlers can hammer your server. Check for repeated requests from the same IP:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

Block abusive IPs with your firewall:

ufw deny from 203.0.113.50

Enable caching. If you are running WordPress, install a caching plugin. For custom applications, implement page or object caching with Redis or Memcached.

Optimize PHP. Adjust PHP-FPM pool settings to limit the number of worker processes:

# Edit the pool config
nano /etc/php/8.2/fpm/pool.d/www.conf

Key settings to adjust:

pm = dynamic
pm.max_children = 10
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 5

Restart PHP-FPM after changes:

systemctl restart php8.2-fpm

Database Overload (MySQL/MariaDB/PostgreSQL)

Symptoms: mysqld, mariadbd, or postgres processes consuming high CPU.

Fixes:

Check for slow queries. Enable the slow query log (MySQL/MariaDB):

# Check if slow query log is enabled
mysql -e "SHOW VARIABLES LIKE 'slow_query_log';"
Enable it if needed
mysql -e "SET GLOBAL slow_query_log = 'ON';"
mysql -e "SET GLOBAL long_query_time = 2;"

Review the slow query log for problematic queries:

tail -50 /var/log/mysql/mysql-slow.log

Check running queries:

mysql -e "SHOW FULL PROCESSLIST;"

Kill stuck or long-running queries:

mysql -e "KILL [query_id];"

Optimize tables and add indexes. Missing indexes are one of the most common causes of database CPU spikes. Analyze your slow queries and add appropriate indexes.

Increase MySQL buffer pool. If your database is large, increase the InnoDB buffer pool to reduce disk reads:

# Edit MySQL config
nano /etc/mysql/mysql.conf.d/mysqld.cnf

Add or modify:

innodb_buffer_pool_size = 1G

Adjust the value based on your available RAM (typically 50-70% of total RAM if the server is primarily a database server). Restart MySQL.

Runaway Application Process

Symptoms: A specific application process (Node.js, Python, Java) is consuming all CPU.

Fixes:

Check application logs for errors or infinite loops.

Restart the application:

systemctl restart your-application

Check for memory leaks. If the application gradually consumes more resources over time, it may have a memory leak that eventually causes CPU thrashing when swap is used.

Set resource limits. Use ulimit or systemd resource controls to prevent a single process from consuming all CPU:

# In the systemd service file
CPUQuota=80%
MemoryMax=2G

Cron Jobs

Symptoms: CPU spikes at regular intervals matching cron schedules.

Fixes:

Review scheduled cron jobs:

crontab -l
ls /etc/cron.d/
ls /etc/cron.daily/

Stagger cron job timing. If multiple heavy jobs run at the same time (e.g., all at midnight), spread them across different times.

Optimize cron job scripts. Review the scripts being executed and look for inefficiencies — unnecessary loops, unoptimized database queries, or excessive disk operations.

Step 4 — Monitor Over Time

After applying fixes, monitor CPU usage to confirm the issue is resolved:

# Watch CPU usage for the next 5 seconds, repeating
vmstat 5
Monitor specific process CPU usage
pidstat -p [PID] 5

Use the resource monitoring graphs in your Data Mammoth dashboard to track CPU usage trends over hours and days.

When to Upgrade Your Plan

If your CPU usage is consistently high (above 70-80%) under normal operating conditions and you have already optimized your applications:

Your workload has outgrown your current plan.
Upgrade to a plan with more vCPUs.
Consider a VDS plan if you need guaranteed, dedicated CPU performance.

See How to Choose the Right VPS Plan for guidance on selecting the right plan.

Prevention Tips

Set up monitoring alerts. Configure alerts for CPU usage thresholds so you are notified before the server becomes unresponsive.
Keep software updated. Newer versions of applications, databases, and frameworks often include performance improvements.
Use caching aggressively. Page caching, object caching, and CDNs reduce the amount of processing your server needs to handle.
Regularly review and optimize. Periodically review your server's resource usage patterns and optimize configurations as your workload evolves.

Need Help?

If you cannot identify the cause of high CPU usage or need help optimizing your server, open a support ticket from your Data Mammoth dashboard. Include the output of top or htop (a screenshot or copy-paste) and a description of when the issue started. Our team can help diagnose and resolve performance issues efficiently.

Was this article helpful?

← Back to Troubleshooting Browse all categories →

Still have questions?

Contact Support →Submit a Ticket

Step 1 — Check Current CPU Usage

Using top

Using htop (Recommended)

AlmaLinux / Rocky / CentOS

Quick Snapshot (Non-Interactive)

Step 2 — Identify the Culprit

Common High-CPU Processes and What They Mean

Investigating an Unknown Process

Check where the binary is located

Check when the process started

Check what files the process has open

Step 3 — Apply Fixes for Common Causes

Web Server Overload (Apache/Nginx + PHP)

Database Overload (MySQL/MariaDB/PostgreSQL)

Enable it if needed

Runaway Application Process

Cron Jobs

Step 4 — Monitor Over Time

Monitor specific process CPU usage

When to Upgrade Your Plan

Prevention Tips

Related Articles

Need Help?

Step 1 — Check Current CPU Usage

Using top

Using htop (Recommended)

AlmaLinux / Rocky / CentOS

Quick Snapshot (Non-Interactive)

Step 2 — Identify the Culprit

Common High-CPU Processes and What They Mean

Investigating an Unknown Process

Check where the binary is located

Check when the process started

Check what files the process has open

Step 3 — Apply Fixes for Common Causes

Web Server Overload (Apache/Nginx + PHP)

Database Overload (MySQL/MariaDB/PostgreSQL)

Enable it if needed

Runaway Application Process

Cron Jobs

Step 4 — Monitor Over Time

Monitor specific process CPU usage

When to Upgrade Your Plan

Prevention Tips

Related Articles

Need Help?

Using `top`

Using `htop` (Recommended)

Using `top`

Using `htop` (Recommended)