Quick answer
High CPU and load on Linux is most often caused by a single process consuming too many resources, whether due to an application bug, poor configuration, or an external attack. Use `top`, `htop`, and `ps` to find the process, check whether it is a legitimate service, then optimize, limit, or restart it. If the problem recurs, analyze logs and configuration.
How to recognize the problem
- Server responds slowly, SSH commands lag
- Load average is consistently above the number of CPU cores
- Website or application runs slowly
- Computer fans run at full speed
- Monitoring sends high CPU alerts
Most common causes
Process consuming too much CPU
An application, database, or script may enter a loop or have a bug that consumes 100% of a core. This is the most common cause of high load.
Poorly configured service
Nginx, MySQL, PHP-FPM, or another service may be misconfigured, spawning too many worker processes or requests. Check the configuration and number of processes.
External attack or bots
An attack or aggressive indexing can generate a large number of requests and overload the CPU. Check access logs and protect the service.
Lack of memory (swap)
When RAM runs out, the system starts using swap, which drastically increases load and slows down operation. Check `free -h` and `vmstat`.
Stuck or non-terminating processes
Scripts that never finish or processes in a long-lasting `D` state (waiting for I/O) can increase load. Zombie processes themselves do not consume CPU but may indicate a problem with the parent process. Review the process list and their states.
Step-by-step fix
- 1
Check current load
Run
uptimeto see the load average for 1, 5, and 15 minutes. Compare the values with the number of CPU cores (nproc). If the load is higher than the number of cores, the system may be overloaded, especially if CPU usage is also near 100%. - 2
Identify the CPU-consuming process
Run
topand pressPto sort by CPU usage. Pay attention to the%CPUandCOMMANDcolumns. For a clearer view, installhtop(sudo apt install htoporsudo dnf install htop) and run it. - 3
Review all processes and their details
Use
ps aux --sort=-%cpu | head -n 10to see the top 10 processes by CPU. For details about a specific process (PID), useps -p PID -o pid,ppid,cmd,%cpu,%mem. - 4
Check if the process is legitimate
Based on the process name and path, determine whether it belongs to a known service (e.g.,
nginx,mysqld,php-fpm). If unsure, check when the process started (ps -p PID -o lstart) and who started it (ps -p PID -o user). - 5
Analyze application logs
Review the logs of the suspicious service:
journalctl -u service_name -n 50or files in/var/log/. Look for errors, repeating messages, or unexpected requests. - 6
Check memory and swap
Run
free -handvmstat 1 5. If thesi/socolumns are increasing (active swapping), lack of RAM may be the cause of high load. Consider adding memory or reducing the number of processes. - 7
Stop or restart the problematic service
If you identify the service, restart it:
sudo systemctl restart service_name. If the process is unknown and suspicious, first try to stop it safely:sudo systemctl stop service_nameorsudo kill -15 PID. Usesudo kill -9 PIDonly as a last resort, as it can lead to data loss or corruption. If the service writes data or uses a database, make a backup before intervening. - 8
Limit resources for the service
For services under systemd, you can set limits in the unit file (e.g.,
CPUQuota=50%). After modifying the unit file, runsudo systemctl daemon-reloadand restart the service. For PHP-FPM, setpm.max_children, and for the database,max_connections. Consult the documentation for exact parameters. - 9
Check if it is an attack
Review the web server access logs (
/var/log/nginx/access.logor similar) and look for a large number of requests from the same IP address. If needed, block the IP via firewall (sudo ufw deny from IP) or set up rate limiting.
If nothing helps: deeper analysis
If high load recurs and you cannot attribute it to any process, use advanced tools. pidstat -u 1 shows per-process CPU usage in real time (if the sysstat package is installed). sudo iotop shows disk I/O, and vmstat 1 gives an overview of system resources. For detailed CPU analysis, use perf top (if installed) or strace -p PID to see the process's system calls; strace can slow down the process, so use it briefly. Also, check for hardware issues (e.g., overheating) using sensors or dmesg | grep -i error. If you suspect compromise, run rkhunter or chkrootkit as root and review cron jobs: crontab -l shows only the current user's jobs, but as root you can use sudo crontab -l -u user or check /etc/crontab, /etc/cron.*, and /var/spool/cron.
How to prevent it
- Regularly update software and follow security patches
- Set up monitoring (e.g., `monit`, `netdata`) and alerts for high load
- Configure resource limits for services (systemd, PHP-FPM, database)
- Review logs and analyze load trends
When to call a professional
If you cannot identify the process, suspect a compromise, or need to change the configuration of critical services, contact an IT expert. They can quickly isolate the cause and prevent prolonged downtime.
IT infrastructure maintenance · Servers, networks, backup, security and helpdeskFAQ
What does load average mean and what value is acceptable?
Load average shows the average number of processes waiting for CPU or I/O over the last 1, 5, and 15 minutes. As a rule of thumb, it is acceptable to be less than or equal to the number of CPU cores. If it is consistently higher, the system may be overloaded.
How can I temporarily reduce load without restarting the server?
You can stop or restart the problematic service, temporarily limit CPU quota for the process (e.g., `cpulimit`), or disable unnecessary services if you are sure they are not needed. For a quick intervention, use `sudo kill -15 PID` on the process consuming the most; use `sudo kill -9 PID` only as a last resort and not on production databases without a prior backup.
Is high load always a CPU problem?
No. High load can be caused by a slow disk (I/O wait), lack of memory (swap), or a large number of processes in an unfinished state. Therefore, check `vmstat`, `iostat`, and `free -h` before concluding that the CPU is the culprit.