How to Fix High CPU Usage on a Linux VPS: 12 Troubleshooting Steps

High CPU usage on a Linux VPS can cause slow websites, delayed application responses, database timeouts, and unreliable server performance. When processor utilisation remains high, even simple operations may take longer than expected.

However, upgrading to a larger VPS is not always the solution. High CPU usage can result from inefficient applications, background processes, database queries, PHP workers, scheduled jobs, or excessive incoming traffic.

This guide explains how to diagnose high CPU usage on Ubuntu, Debian, AlmaLinux, Rocky Linux, and other Linux VPS systems using common administration tools.

It also covers practical optimisation methods to improve performance without making unnecessary infrastructure changes.

Command verification: These commands are illustrative administration examples reviewed against the documentation linked below. They have not been run on a live DigitalBerg VPS. Package installation and configuration edits change your system; back up configuration files and test changes in staging before production. Service names and paths vary by distribution. The systemctl examples require systemd.

What Causes High CPU Usage on a Linux VPS?

A Linux VPS can experience excessive CPU utilisation for several reasons:

• High website traffic or automated bot requests
• Resource-intensive PHP or WordPress plugins
• Slow MySQL or MariaDB queries
• Background scripts and scheduled cron jobs
• Excessive Apache or Nginx application requests
• Misconfigured PHP-FPM worker processes
• Malware or unauthorised cryptocurrency mining
• Software bugs or processes stuck in repeated execution loops
• CPU contention on shared virtualisation infrastructure
• Insufficient CPU capacity for the current workload

Before making configuration changes, administrators should identify which processes are consuming resources and whether the issue is temporary or persistent.

Step 1: Check CPU Usage With the top Command

The top command provides a live overview of Linux processes, CPU utilisation, memory usage, and system load.

Connect to the VPS using SSH and run:

top

The output displays running processes and system statistics.

Important fields include:

Press P to sort processes by CPU usage, or press q to exit.

A process consistently consuming significant CPU resources may require further investigation.

Important: In many Linux process-monitoring tools, 100% CPU for a process represents approximately one logical CPU. A multithreaded process can exceed 100% on a multi-core server.

Step 2: Install and Use htop for Better Process Monitoring

htop provides an interactive interface for viewing system processes and resource usage.

For Ubuntu or Debian:

sudo apt update
sudo apt install htop

For AlmaLinux or Rocky Linux:

sudo dnf install htop

If the package is unavailable, the appropriate repository may need to be enabled.

Start monitoring:

htop

Administrators can inspect:

• CPU usage across individual logical processors
• Memory and swap utilisation
• Running processes and their owners
• Process identifiers
• CPU-intensive applications

Use the sorting and filtering controls to identify processes consuming the most resources.

The process owner and executable path can help determine whether the activity is expected.

Step 3: Identify the Processes Using the Most CPU

The ps command can identify CPU-intensive processes without opening an interactive monitoring tool.

Run:

ps -eo pid,ppid,user,%cpu,%mem,stat,etime,comm --sort=-%cpu | head -n 16

This displays the highest-ranked processes based on CPU utilisation.

For more information about a specific process:

ps -p 1234 -o pid,ppid,user,%cpu,%mem,etime,args

Replace 1234 with the actual process ID.

Administrators should investigate unfamiliar processes before attempting to stop them.

Note: The %CPU value reported by ps generally reflects CPU usage averaged over a process’s lifetime, rather than an instantaneous measurement. Use top, htop, or pidstat to investigate short-lived spikes.

Step 4: Check Linux Load Average

High CPU usage and high load average are related, but they are not identical.

Run:

uptime

Illustrative output (not measured on a live server):

17:35:22 up 12 days, 4:15, 2 users, load average: 3.80, 3.20, 2.75

The three load averages represent approximately the last 1, 5, and 15 minutes.

Check the number of available logical CPUs:

nproc

CPU affinity and container or service quotas can limit effective capacity; the visible CPU count alone may not describe those limits.

A sustained load average significantly higher than the available logical CPU count can indicate contention or processes waiting for resources.

However, Linux load average also includes tasks waiting in uninterruptible states, commonly associated with I/O. Therefore, a high load average does not always mean the CPU itself is saturated.

Use load average alongside CPU, memory, and disk monitoring for accurate diagnosis.

Step 5: Investigate High CPU Usage From MySQL or MariaDB

Database operations are a common source of server performance problems.

Poorly optimised queries, missing indexes, and inefficient applications can increase database CPU usage.

First, check whether the database service is running:

systemctl status mariadb

Or, on systems using MySQL:

systemctl status mysql

Some MySQL installations use mysqld instead of mysql. Check the installed unit name rather than assuming a missing service means the database is stopped.

To examine active database queries, connect using an authorised database account and run:

SHOW FULL PROCESSLIST;

Look for unusually long-running active queries. A long-lived sleeping connection is not evidence of CPU consumption. Seeing other users’ sessions requires appropriate database privileges; elapsed time alone does not prove a query is CPU-bound.

For a deeper investigation, administrators can temporarily enable slow query logging through a properly reviewed database configuration.

Example MySQL configuration directives:

[mysqld]
slow_query_log = ON
long_query_time = 2

These settings are illustrative. The correct configuration file, logging destination, permissions, and activation procedure depend on the database version and distribution.

Slow query logs can help identify expensive SQL operations. Limit collection time, monitor log growth and protect logs because query text may contain sensitive data.

Common optimisation techniques include:

• Adding appropriate database indexes
• Reducing unnecessary queries
• Reviewing inefficient joins
• Optimising application database access
• Checking WordPress plugins that generate excessive queries

Database configuration changes should be tested before applying them to production workloads.

Step 6: Optimise PHP-FPM Worker Configuration

PHP-FPM manages PHP application processes for many Linux web hosting environments.

Incorrect worker settings can contribute to excessive CPU usage, memory pressure, or request queuing.

Check the PHP-FPM service:

systemctl list-units --type=service --all | grep -i php

Service names vary by operating system and installed PHP version.

Common PHP-FPM settings include:

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

These are illustrative values, not universal recommended settings.

The correct number of PHP workers depends on:

• Available RAM
• Average memory consumption per PHP process
• CPU resources
• Request concurrency
• Application execution time

Increasing worker counts without measuring resource consumption can make an overloaded VPS perform worse.

Administrators should monitor PHP process utilisation and review PHP-FPM slow logs where available. Validate the configuration using the installed PHP-FPM binary’s configuration-test option before a controlled reload; binary names vary by PHP version.

Step 7: Check Apache or Nginx for Excessive Requests

Unexpected traffic can overload web applications and increase CPU utilisation.

Check the web server service:

systemctl status apache2

On distributions using the httpd service:

systemctl status httpd

For Nginx:

systemctl status nginx

Administrators can also inspect access logs to identify unusual request patterns.

Example for a conventional Nginx access log:

sudo tail -n 100 /var/log/nginx/access.log

To identify frequently occurring client addresses in a standard combined log format:

sudo tail -n 10000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head

This examines only the last 10,000 lines, not the entire traffic history or a fixed time interval. This command assumes the first log field contains the actual client IP address. Reverse proxies and custom log formats may require different analysis.

Potential warning signs include:

• Repeated requests to login pages
• Large numbers of requests from automated clients
• Excessive requests to expensive application endpoints
• Sudden increases in uncached traffic

Rate limiting, application caching, a properly configured CDN, and suitable security controls can help reduce unnecessary server workload.

Avoid blocking IP addresses solely because they appear frequently in logs. Legitimate users, monitoring systems, and shared proxies can generate substantial traffic.

Step 8: Find CPU-Intensive Cron Jobs

Scheduled jobs can create CPU spikes, especially when several tasks execute simultaneously.

Inspect the current user’s cron configuration:

crontab -l

For root’s cron jobs, where authorised:

sudo crontab -l

System-wide scheduled tasks may be stored in:

/etc/crontab
/etc/cron.d/
/etc/cron.daily/
/etc/cron.hourly/

On systems using systemd timers:

systemctl list-timers --all

Common resource-intensive scheduled tasks include:

• Database backups
• File compression
• Website indexing
• Malware scans
• Application maintenance
• Log processing

If several tasks run at the same time, staggering their schedules may reduce peak resource usage.

Do not disable backup, security, or maintenance jobs without understanding their purpose.

Step 9: Investigate Suspicious Processes and Malware

Unexpected CPU consumption may occasionally indicate unauthorised software.

Inspect unfamiliar processes:

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

For a suspicious process, identify its executable:

sudo readlink -f /proc/1234/exe

Replace 1234 with the relevant process ID.

Review the process’s command-line arguments, owner, network activity, and persistence mechanisms.

Unexpected cryptocurrency mining software, compromised application scripts, and unauthorised scheduled tasks can consume substantial resources.

If compromise is suspected:

1. Preserve relevant logs and evidence.
2. Restrict unauthorised access.
3. Investigate affected accounts and services.
4. Rotate compromised credentials using a trusted environment.
5. Restore or rebuild affected systems from trusted sources where necessary.

Simply terminating a suspicious process may not remove the underlying compromise.

Step 10: Check CPU Steal Time on a VPS

A VPS shares physical infrastructure with other virtual machines unless the service provides dedicated CPU resources.

CPU steal time represents time during which a virtual CPU was ready to run but the hypervisor did not schedule it.

Run:

top

Look for the st field in the CPU summary.

You can also use:

vmstat 1 5

This prints five reports: the first includes CPU and I/O averages since boot, and the remaining reports cover one-second intervals. Judge current activity from those interval reports.

Sustained elevated steal time during periods of poor performance may indicate host-level CPU contention.

However, steal time must be interpreted alongside application demand, virtualisation type, and the provider’s resource allocation model.

If elevated steal time persists, contact the hosting provider with timestamps and monitoring evidence.

Step 11: Check Memory Pressure and Disk I/O

A slow Linux VPS does not necessarily have a CPU bottleneck.

Memory shortages, swapping, and disk latency can create symptoms similar to CPU saturation.

Check memory:

free -h

Check disk capacity:

df -h

Inspect virtual memory statistics:

vmstat 1 5

For detailed disk statistics, install sysstat if needed and run:

iostat -xz 1 5

For free, focus on the available-memory estimate rather than free memory alone: filesystem caches are often reclaimable. In vmstat, sustained non-zero si and so can indicate active swapping. The first iostat report covers time since boot; later reports cover each sampling interval. Review await and workload patterns; %util alone is not a universal saturation threshold for modern parallel storage. I/O wait is idle CPU time with outstanding I/O, not CPU executing work.

When storage or memory is the actual bottleneck, adding CPU cores may not improve application performance.

Step 12: Decide Whether to Optimise or Upgrade the VPS

After identifying the cause of high CPU usage, administrators can decide whether configuration changes or additional resources are necessary.

Optimisation may be sufficient when:

• A specific application is generating inefficient queries.
• Excessive scheduled jobs are running simultaneously.
• Web caching is missing or misconfigured.
• PHP worker settings are unsuitable.
• Unnecessary background services consume resources.

A VPS upgrade may be appropriate when:

• Legitimate application demand consistently saturates available CPU capacity.
• The workload has already been reasonably optimised.
• Traffic growth requires more processing resources.
• Resource limits are regularly reached during expected usage.

Before upgrading, review CPU, memory, storage, and network utilisation over a representative period.

DigitalBerg offers Cloud VPS Hosting and Dedicated Server Hosting for customers evaluating different infrastructure requirements.

The appropriate hosting solution depends on workload characteristics, resource needs, and the level of control required.

Quick Linux VPS CPU Troubleshooting Checklist

Frequently Asked Questions

Why is my Linux VPS CPU usage at 100%?

A Linux VPS can reach 100% CPU utilisation because of demanding applications, excessive traffic, database queries, scheduled tasks, or insufficient allocated resources. Use top, htop, or pidstat to identify the processes responsible before changing server settings.

How do I reduce CPU usage on Ubuntu VPS?

Start by identifying resource-intensive processes. Then investigate application logs, database queries, PHP-FPM configuration, background tasks, and caching. Apply changes based on measured bottlenecks rather than stopping services indiscriminately.

Is high CPU usage dangerous for a VPS?

High CPU usage is not automatically dangerous. Modern processors are designed to operate under load. However, sustained CPU saturation can increase response times, cause request queues, and reduce application performance.

What is a normal CPU usage percentage for a Linux VPS?

There is no universal ideal percentage. Acceptable CPU utilisation depends on workload characteristics, available cores, latency requirements, and traffic patterns. Sustained saturation combined with increased response times is more concerning than short CPU spikes.

Can WordPress plugins cause high CPU usage?

Yes. Plugins may trigger expensive database queries, repeated background operations, or resource-intensive PHP execution. Administrators can use application profiling, database slow query logs, and staging tests to investigate.

Does adding RAM reduce CPU usage?

Additional RAM can improve performance when memory pressure or swapping contributes to the problem. However, adding RAM does not directly resolve CPU-intensive application code or inefficient processing.

What is CPU steal time in Linux VPS hosting?

CPU steal time is the time a virtual machine spends waiting for the hypervisor to schedule its virtual CPU. Persistent elevated steal time may indicate host-level resource contention and should be investigated with the hosting provider.

Should I restart my VPS when CPU usage is high?

A restart may temporarily restore responsiveness, but it does not necessarily fix the underlying cause. Administrators should collect diagnostic information before restarting whenever possible, especially when the problem is recurring.

Final Thoughts

High CPU usage on a Linux VPS should be approached systematically.

Monitoring tools such as top, htop, ps, vmstat, and iostat help administrators distinguish CPU saturation from memory shortages, storage delays, and virtualisation-related contention.

Database optimisation, efficient PHP configuration, suitable caching, and properly scheduled background tasks can often improve performance without additional hardware.

When legitimate application demand consistently exceeds available resources, upgrading to a larger VPS or dedicated server may be appropriate.

For more information about Linux hosting infrastructure, explore DigitalBerg’s VPS Hosting, SSD Web Hosting, and Knowledge Base.

DigitalBerg Technical Team | Linux Hosting, VPS Infrastructure and Server Performance

Technical References

• Linux top manual
• Linux ps manual
• Linux vmstat manual
• iostat manual
• Official PHP-FPM configuration documentation
• MySQL slow query log documentation