When a site that was fast yesterday crawls today, the panel takes ages to load, or monitoring reports the server is unresponsive, load is the first suspect. Upgrading the plan or rebooting in a panic is usually the wrong move: the cause stays and the problem returns within hours. The right move is to find out what creates the load. The steps below are written for VPS owners, but the logic applies to shared hosting too, where some of the data comes from the panel or support.
Step 1: is the load really high?
uptime shows the 1, 5 and 15 minute load averages, which only mean something relative to the core count from nproc. On a 4-core server, a load of about 4 means fully busy; 20 means a serious queue.
uptime
nproc
free -h
df -hfree -h shows memory and swap; when memory runs out, the kernel starts killing processes. df -h checks the disk, and a full disk stops logging, databases and sessions. Sometimes the "load problem" is really a full disk.
Step 2: which process is eating resources?
ps aux --sort=-%cpu | head -15
ps aux --sort=-%mem | head -15Many php-fpm or httpd processes mean heavy traffic; mysqld at the top means expensive queries. An unfamiliar process with an odd name, or one launched from /tmp, pinning the CPU at 100% may be a cryptominer. Kill it immediately, then find out how it got there, because miners usually restore themselves through cron. If the CPU is mostly idle but load is high, check the wa (iowait) value in top; processes are waiting on disk, and iotop shows who is writing the most.
Step 3: who is hitting the site?
The cause is often external: search bots, AI crawlers, password-guessing scripts or a DDoS. The access log tells you who:
awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -20
awk -F'"' '{print $6}' access.log | sort | uniq -c | sort -rn | head -10
grep -c "wp-login.php" access.logThese list the busiest IPs, the top User-Agents and the number of login page hits. An online shop in Tashkent saw load jump tenfold overnight; the log showed a single bot crawling catalog filter pages in thousands of combinations. Disallowing the filter URLs in robots.txt and limiting the bot brought load back to normal in minutes.
If a single IP sends hundreds of requests per minute and does not belong to a known search engine, block it temporarily. On Apache 2.4 you can do it in .htaccess as shown below, although on a VPS blocking at the firewall level is more efficient because the request never reaches the web server at all:
<RequireAll>
Require all granted
Require not ip 203.0.113.50
</RequireAll>Step 4: cron and background jobs
If load rises at the same time every day, a scheduled task such as a backup, import or mailing is the likely culprit:
crontab -l
ls /etc/cron.d/On WordPress, wp-cron.php runs background tasks on every visit. Add define('DISABLE_WP_CRON', true); to wp-config.php and call it from a real cron every 5 or 15 minutes instead. Also check that copies of one job are not overlapping; wrapping the command in flock prevents a new run from starting before the previous one finishes.
Step 5: heavy database queries
mysql -e "SHOW FULL PROCESSLIST;"If the same query repeats dozens of times and sits in "Sending data" or "Locked", a table is probably missing an index or a plugin is sending an inefficient query. For longer-term analysis, enable the slow query log, which records queries that exceed a set duration.
Write down what you found
Once you know the cause, note when it started, which process or IP was responsible and how you fixed it; next time it will save you time. On shared hosting where you cannot run server commands, contact support from the sayt.uz cabinet and say when the load rose, so the cause can be traced in the server logs.