Server overloaded, websites slow, or CPU and memory suddenly too high?
A server under heavy load can stay technically online while becoming almost unusable. Restarting it may restore performance temporarily — it won’t explain why the load increased. We find which process, service or workload is consuming the resources, and why.
Load average isn’t just CPU usage
A server can show high load because processes are actively using CPU, waiting for CPU time, waiting for disk I/O, or blocked by storage. A load average of 10 doesn’t mean the same thing on every server — it depends on core count, I/O wait, memory, swap and the actual workload. We look at the complete resource picture, not a single number.
When the processor is the bottleneck
PHP, MySQL, cron/backup jobs, malware, cryptominers, bot traffic or badly written code. We identify what’s consuming CPU before recommending more of it.
We check who started it, how long it’s run, what it touches, whether it’s legitimate — killing it helps short-term, but knowing why it exists matters more.
Traffic surge, PHP-FPM saturation, a database-heavy workload, a maintenance job, or a compromised server — we check whether the load is actually expected.
High load, low CPU? It’s probably disk I/O
A high load average with relatively low CPU usage usually points to processes waiting on storage, not the processor. Common causes: overloaded disks, heavy database activity, backups, RAID operations, filesystem problems, or excessive swap. If the underlying storage is the actual bottleneck, adding CPU or RAM won’t help much.
Swap, OOM events and what gets killed
Some swap is normal. The problem is active swapping — large amounts of memory moving between RAM and disk, which can badly hurt performance.
Under severe memory pressure, the kernel terminates a process to keep the system alive — often MySQL, PHP-FPM or Redis. We check the logs for what actually happened.
Bringing a killed service back up without fixing the memory problem just delays the next failure.
Too many workers, or too few
If each PHP process uses significant RAM, allowing hundreds of simultaneous workers can destabilise the whole server. We check pm.max_children and related settings against actual process memory.
Requests queue even when CPU and RAM are free — slow sites, 504 errors, “max_children reached” warnings during traffic spikes.
Tuning is never just “reduce the limits” — it has to match the workload and the RAM actually available.
MySQL, MariaDB and Redis
Slow queries, missing indexes, large table scans, locks, high connection count, or poorly configured memory.
Raising max_connections isn’t automatically the fix — more connections mean more memory, which can make things worse.
No maxmemory limit lets Redis eat available RAM meant for MySQL and PHP. Redis should help performance, not compete for it.
Often the real source of the load
Poorly written plugins, wp-cron, backup plugins, security scans, broken cache, XML-RPC abuse, REST API traffic, admin-ajax requests and bots. WooCommerce adds checkout activity, scheduled actions and inventory operations on top.
Backups, RAID and cron jobs
Compression of large sites/databases can spike CPU, I/O and memory. A backup shouldn’t repeatedly take production offline.
On dedicated servers, rebuilds generate real I/O. The server stays up but everything gets slower until it finishes.
Predictable load spikes at fixed times — backups, DB optimisation, log rotation, malware scans, imports.
When the load isn’t organic
Search bots, AI crawlers, SEO tools, scanners, aggressive scraping — restricted via NGINX/Apache, firewall, Fail2Ban or Cloudflare.
Sudden spikes may be an attack, not demand — sometimes needs provider-level or Cloudflare protection, not just server config.
Repeated login attempts against SSH, WordPress, email or panels — Fail2Ban and firewall restrictions.
Unknown processes, restarting after being killed, suspicious cron — sometimes a clean rebuild is safer than continuing to trust the server.
CPU steal time — a bottleneck outside your control
Steal time is what Linux reports when your VM is waiting for the physical host’s CPU. Consistently high steal time points to contention on the virtualization host, not a problem inside your VPS — tuning PHP or MySQL settings won’t fix an overloaded physical host. In these cases, provider intervention or migration may be the actual answer.
One website, or all of them?
We correlate logs, PHP processes, database activity and traffic per domain — usually a traffic spike, broken plugin, malware or bots.
Points to a shared component: CPU/memory exhaustion, disk I/O, MySQL, PHP-FPM, a backup or RAID job, or the provider infrastructure itself.
Migration, PHP upgrade or MySQL/MariaDB changes can all shift resource behaviour — different CPU/storage performance, missing Redis, altered PHP-FPM pools, or database settings copied from a different server without adjusting for available resources.
It can restore performance quickly, but it also erases the evidence. Where possible, we capture the process list, CPU/memory/swap/I/O and logs first. If the server is genuinely unusable, a reboot may still be necessary — the important part is figuring out the cause afterward.
Maybe — but not before finding the bottleneck
A larger server helps when the workload genuinely needs more CPU, RAM or storage performance. It won’t fix broken application code, a runaway process, slow queries, malware, bot traffic, a full disk, bad Redis config or excessive backup activity.
We measure the problem before recommending more infrastructure.
Faster diagnosis starts with the right details
Standard investigation, unless production is already down
Standard Support — normal Linux performance investigation, not yet a critical outage.
Emergency Support — if the high load is causing a critical production outage.
Out-of-Hours Emergency — evenings, weekends, holidays.
Priority and emergency work is subject to administrator availability. Full pricing →
High load doesn’t always mean you need a bigger server
The most important part of performance troubleshooting is separating a capacity problem from a configuration or application problem. Sometimes the answer is more CPU or RAM. Often it’s one slow query, one PHP process, one plugin, one backup job, one aggressive crawler, one compromised website, or one wrong memory limit.
More than 22 years of practical experience with Linux servers, hosting infrastructure, PHP, MySQL, MariaDB, Redis, WordPress and production workloads.
Measure the bottleneck, identify what’s consuming the resources, and correct the underlying cause wherever possible.
Server acting up right now?
Tell us what’s happening — we’ll help you find the actual bottleneck.