Server at 100% CPU: Find the Culprit Site and Stop Bot Traffic

A server pinned at 100% CPU or RAM usually has one of two causes: real traffic your current resources can’t handle, or bot traffic hitting the parts of your sites that were never meant to be cached. This runbook walks through finding which one it is, and what to do about each.

Step 1: Find the busy site

If you have multiple sites on the server, don’t assume — check which one is actually responsible before you touch anything.

• Open Server → Monitoring to see overall CPU, RAM and disk usage for the server.
• Open each site’s own monitoring page to compare per-site CPU and RAM (see How to Monitor the RAM, CPU & Disk Usage of a Site).
• Check that site’s traffic and access logs for a burst of requests, or the same handful of paths being hit over and over.

Step 2: Is it bots?

Signs that point to bot traffic rather than organic growth:

• A spike in requests with no matching spike in real visitors (analytics, orders, form submissions).
• Repeated hits on the same few URLs — especially search pages, cart/checkout, or anything with query parameters.
• Unusual or generic user agents in the access log, or a long list of different IPs all requesting the same path.

Step 3: Block the bots

• AI Bot Blocker blocks 180+ known AI bot and scraper user agents. Enable it under Tools → Nginx and Security on NGINX servers, or Tools → Security on OpenLiteSpeed servers.
• The 7G or 8G firewall covers a wider set of bad-bot patterns beyond AI crawlers — older scrapers, SEO tools like ahrefs and mj12bot, and generic curl/wget clients. It lives in the same Tools → Nginx and Security area. You can only run one of 7G or 8G at a time — enabling one turns the other off.
• For a persistent or targeted attack that outlasts these, put the site behind a CDN or WAF (such as Cloudflare) in front of xCloud.

Step 4: Check WooCommerce cart and checkout

If the busy site is a WooCommerce store, check whether the hot paths are cart, checkout or my-account URLs. These are excluded from xCloud’s full page cache by default — that’s expected behavior, since they carry per-visitor state like cart contents and login status. It also means bots repeatedly requesting those exact URLs hit PHP every single time instead of a cached page, which is a common way a WooCommerce site gets driven to 100% CPU by traffic that looks small in analytics.

Blocking the bot traffic (Step 3) is the fix here — you can’t safely cache your way out of it, since caching those pages for everyone would show one visitor’s cart to another.

Step 5: Contain the damage with PHP-FPM limits

Even with bots blocked, one site shouldn’t be able to take down the whole server. Cap how many PHP worker processes a site can use:

• Open the site’s PHP settings and use Auto Tune to calculate pm.max_children and related values based on the server’s available RAM (see How to Configure PHP Settings).
• A lower pm.max_children makes worker exhaustion degrade that one site gracefully — visitors to it may see slow responses — instead of saturating the server for every site on it.

If it isn’t bots

If traffic genuinely is what it looks like, the fixes are different:

• OPcache and PHP-FPM tuning — review the site’s PHP settings and Auto Tune values; see Controlling OPcache with xCloud.
• Database settings — check whether MySQL/MariaDB configuration matches the server’s resources; see Auto-tune MySQL/MariaDB configurations.
• Cron jobs and heavy plugins — a runaway cron job or a plugin doing expensive work on every request can look identical to a traffic spike. Check Cron Jobs and recently active plugins.
• xCloud does not expose Redis memory or eviction tuning to customers — if Redis looks implicated, that’s one for support, not a dashboard setting.

A reboot alone does not fix any of the causes above — it just buys a few minutes before the same demand returns.

When to upgrade the server

If you’ve confirmed it’s real traffic (not bots), blocked what you can, and tuned PHP-FPM and the database, and the server is still consistently maxed out, that’s a sign the server needs more CPU or RAM for the load it’s actually serving. See how to upgrade your server in xCloud.

Still stuck? Contact our support team for any of your queries.

Frequently asked questions

Will restarting the server fix a CPU spike?

It clears the immediate symptom, but not the cause. If the spike was bot traffic or an uncached hot path, the same load returns as soon as traffic resumes — block the source or contain it first.

What’s the difference between AI Bot Blocker and the 7G/8G firewall?

AI Bot Blocker targets AI crawlers and scrapers specifically (180+ known user agents). The 7G/8G firewall covers a wider set of bad-bot patterns — old-style scrapers, SEO tools like ahrefs and mj12bot, and generic curl/wget clients. You can only run one of 7G or 8G at a time, but AI Bot Blocker runs alongside either.

Why are my WooCommerce cart and checkout pages never cached?

xCloud excludes cart, checkout and my-account URLs from full page cache by default, because they carry per-visitor state. This is expected behavior, not a misconfiguration — but it also means bots hammering those exact URLs hit PHP every time instead of a cached page.