LiveChat 
Support 
High Server CPU Usage: What a ‘Pinned’ CPU Means and How to Fix It
Your site slows to a crawl, pages time out, and someone tells you the CPU is “pinned.” It’s an alarming word that usually arrives with a vague sense that something is on fire. It isn’t. A pinned CPU is not a fault the way a crash or a 500 error is — it’s a symptom, and a very readable one. The processor is simply being asked to do more work than it can finish in the time it has, so the queue backs up and everything waits. Fixing it isn’t about panic or blindly upgrading; it’s about finding *what* is doing all that work, then either making that work cheaper or giving it more room to run.
This article is part of our complete guide to website performance, where you can see how CPU fits alongside memory, disk, and network as one of the levers that shapes how fast your site feels.
Key Takeaways
• “Pinned” or 100% CPU means the processor is fully saturated — it has more work queued than it can complete, so requests wait and the site feels slow. It is a symptom, not a crash.
• The cause is almost always identifiable: a traffic spike, an inefficient plugin or query, bots and attacks, a runaway cron job, or simply hitting a shared-hosting CPU limit.
• You diagnose it by looking, not guessing —top/htopon a VPS, or the resource-usage and process tools in cPanel on shared hosting, will name the process eating the CPU.
• The fix depends on the cause: optimise the code and queries, add caching, block bad traffic, and tame cron — then measure again before touching hardware.
• When the workload legitimately outgrows the box, the honest answer is more CPU: moving from a shared account with hard limits to a VPS with dedicated cores.
What does “high CPU usage” or a “pinned” CPU actually mean?
CPU usage is simply the percentage of time your processor spends busy rather than idle. At 20% it has plenty of headroom. At 100% — “pinned” — it is busy every available moment, with no headroom left.
The important thing is what happens *next*. A CPU can’t do more than 100%; that’s the ceiling. When more requests arrive than it can finish, they don’t vanish — they queue behind the work already in progress. This is why a pinned CPU *feels* like slowness rather than an error: nothing has broken, but everything is standing in line. Pages take longer, queries lag, and under enough load, requests wait so long they time out.
On a multi-core server, “100%” can mean different things by tool: some report per-core (one maxed core reads as 100% while others idle), some average across all cores. A single-threaded process — one PHP request, one runaway script — can pin one core while the rest of the machine sits nearly idle, and that’s often exactly what’s happening.
A pinned CPU isn’t, by itself, damage; servers are built to run hot when there’s work to do. The problem is only when it stays pinned *and* there’s more demand than it can serve — that’s when visitors feel it.
Why does high server CPU usage happen?
High CPU is a symptom, and a handful of distinct causes produce it. In practice it’s almost always one of these:
- A genuine traffic spike. More visitors means more requests, more pages to render, more queries to run. A landing campaign or seasonal rush can legitimately drive CPU to the ceiling. This is the “good” cause — real demand.
- Inefficient code or a heavy plugin. A badly written function, an unoptimised theme, or a plugin doing expensive work on every page load can consume enormous CPU per request. On WordPress especially, one poorly built plugin can dominate the whole account.
- Slow or unindexed database queries. A query that scans an entire table instead of using an index makes the database work far harder than it should. Multiply that by every page view and the CPU is buried in query processing.
- Bots, scrapers, and attacks. Aggressive crawlers, content scrapers, brute-force login attempts, and DDoS traffic all generate requests your server must process — none of it real visitors. Attack traffic can pin a CPU with no legitimate load at all.
- Runaway or overlapping cron jobs. A scheduled task that runs too often, takes too long, or stacks up because the previous run hasn’t finished can quietly saturate a CPU on a fixed schedule.
- Shared-hosting resource limits. On shared hosting you have a *ceiling* — a CPU quota. Perfectly normal traffic can hit it simply because the plan is sized for less, and the host throttles you to protect its other tenants.
Notice the pattern: every one of these leaves evidence. None is invisible — that’s what makes a calm diagnosis possible.
How do I diagnose what’s using the CPU?
You can’t fix what you can’t see, so before changing anything, find the culprit. How you look depends on your hosting.
On a VPS or server with shell access: top and htop
If you have SSH access, the fastest first look is top — a live, sorted list of processes with the heaviest CPU consumers on top. Press P to sort by CPU. The friendlier version is htop, which adds per-core bars and colour so you can see at a glance whether one core is pinned while others idle:
top
htopTo capture a snapshot without an interactive screen — useful for a support ticket — ps sorts by CPU too:
ps aux --sort=-%cpu | head -n 15That prints the fifteen hungriest processes right now. Look at *what* they are: php-fpm or httpd/apache workers point at web requests, mysqld or mariadb points at the database, and a lone script or cron process names itself directly.
The other number to read is load average, shown by top, htop, and uptime. It’s a rough count of processes waiting to run. Compare it to your core count: a load average around your number of cores means the CPU is fully but healthily used; far *above* your core count means work is piling up faster than the CPU can clear it.
uptimeOn shared hosting: cPanel resource usage
Most shared accounts don’t give you shell access, but cPanel exposes the same information. Open Metrics → Resource Usage (sometimes labelled “CPU and Concurrent Connection Usage”). It shows whether your account has been hitting its CPU limit, when, and how often — with graphs so you can line a spike up against something that happened on your site. Some hosts also offer a Process Manager that lists what’s running under your account right now, with its CPU cost. Between the graphs (which tell you *when* you’re maxed out) and the process list (which tells you *what* is responsible), you can usually identify the cause without a command line.
Finding slow queries
If the database is the heavy process, the culprit is usually a specific slow query. Enable the slow query log in MySQL/MariaDB, or use a tool like mysqltuner, to find queries that run long or run often. For WordPress, a query-monitoring plugin shows exactly which queries a page fires and how long each takes — the expensive ones stand out immediately.
Cause, symptom, and fix at a glance
When the CPU is pinned and you’re under pressure, a quick map from cause to fix keeps you moving without losing the method. Match your symptom to the row.
| Cause | Typical symptom | Fix |
|---|---|---|
| Traffic spike | CPU rises with visitor count; real users in analytics | Add page/object caching, a CDN; scale up if it’s the new normal |
| Inefficient plugin/code | One php-fpm process eats CPU; slow on specific pages |
Profile and replace the plugin; optimise the code path |
| Slow database query | mysqld high; slow query log full of long scans |
Add indexes, rewrite queries, cache query results |
| Bots / scrapers / attacks | High requests from few IPs or odd user agents; no real traffic | Block IPs, rate-limit, add a WAF / firewall |
| Runaway cron | CPU spikes on a fixed schedule; overlapping cron processes | Reduce frequency, prevent overlap, offload heavy jobs |
| Shared-hosting limit | cPanel shows account throttled at its CPU quota | Optimise first; then upgrade to a plan or VPS with more CPU |
The middle column always comes from *looking* — a process list, a log, a graph. That’s not a coincidence; it’s the whole method.
How do I fix high CPU usage?
Work through the fixes that match your diagnosis, cheapest and highest-impact first. The order matters — optimising away wasted work is almost always better than paying for hardware to power through it.
Cache aggressively
Caching is the single biggest lever for CPU on a content site, because it lets the server *skip* work entirely. Instead of rebuilding a page from PHP and database queries on every request, it hands back a pre-built copy. Page caching (full-page HTML), object caching (Redis or Memcached for repeated database results), and opcode caching (OPcache, which stores compiled PHP) together turn an expensive dynamic request into a nearly free one. If your CPU is pinned by real traffic, caching often solves it outright — you stop paying full price for each visitor.
Optimise the code and the queries
If a plugin or query is the culprit, make that work cheaper: replace or reconfigure the offending plugin, add database indexes so queries stop scanning whole tables, and eliminate expensive operations that run on every page load. This is targeted surgery, not a rewrite — profiling told you the one thing to fix, so fix that one thing.
Block bad traffic
If the load is bots, scrapers, or an attack, no amount of optimisation helps, because none of it is legitimate work. Rate-limit abusive IPs, block obvious offenders at the firewall, put a web application firewall (WAF) in front of the site, and use a CDN that filters junk traffic before it reaches your server. Stop paying CPU for requests that were never going to convert.
Tame cron
If a scheduled task is the spike, reduce how often it runs, prevent a slow run from overlapping the next, and move heavy jobs to off-peak hours. On WordPress, replacing the default page-load-triggered wp-cron with a real system cron job stops scheduled work from piling onto live visitor requests.
Then, and only then, scale the hardware
Sometimes the workload is legitimate, already optimised, and simply larger than the box you’re on. That’s not a failure — it’s growth, and the honest fix is more CPU.
When you’ve optimised everything and the CPU is still pinned, the box is the bottleneck — and that’s a hardware problem with a hardware fix. Shared hosting shares one server’s CPU across many accounts, with a hard quota that throttles you the moment your real traffic outgrows the plan. A DarazHost SSD Linux VPS (or Windows VPS) gives you dedicated CPU and resources that are *yours* — no noisy neighbours, no shared ceiling — plus root access to profile and tune the machine exactly as you need. Every plan is backed by 99.9% uptime, 24/7/365 support, and fast SSD storage, with a 30-day money-back guarantee so you can move up with confidence. When shared hosting is genuinely maxed out, a VPS is the room your workload has been asking for.
How do I tell a real spike from an attack or a runaway process?
This decides which fix you reach for, and it’s answerable in minutes. Line up three things: your analytics, your process list, and your traffic logs.
If analytics shows a matching surge of real visitors from varied sources, it’s a genuine spike — reach for caching and scaling. If the CPU is high but analytics is flat, the traffic isn’t human: check access logs for a flood from a handful of IPs, a suspicious user agent, or hammering on wp-login.php or xmlrpc.php, and treat it as an attack. If the CPU spikes on a clean schedule and the process list shows a cron or script process, it’s a runaway job. The three signals together almost always point at one cause.
Frequently asked questions
Is 100% CPU usage always a problem? No. A CPU briefly hitting 100% while it finishes a burst of work is normal and even efficient — you paid for that capacity, so using it is fine. It becomes a problem only when the CPU stays pinned *and* there’s more demand than it can serve, so requests queue and visitors wait. Short spikes are healthy; sustained saturation under load is the thing to fix.
What does it mean when my host says my CPU is “pinned”? “Pinned” is informal shorthand for the CPU sitting at or near 100% and staying there — held against the ceiling with no headroom left, work queuing behind what it’s already doing. On shared hosting it often means you’ve hit your account’s CPU quota and are being throttled. Either way, it’s a signal to diagnose the cause, not evidence of a crash.
Why is my CPU usage high when my site has no traffic? Because CPU load doesn’t require *real* visitors. The usual culprits are bots and scrapers, brute-force attacks on your login, a runaway or overlapping cron job, or a background process stuck in a loop. Check your process list and access logs: if the CPU is busy but analytics is flat, the “traffic” is almost certainly automated — and the fix is to block or tame it, not to scale up.
Will upgrading my hosting plan fix high CPU usage? It fixes it when the cause is genuine, optimised load that has simply outgrown your current CPU allocation — then more cores are the right answer. It does *not* fix an unindexed query, a broken plugin, or an attack; those will consume a bigger server just as happily. Diagnose first. If you’ve optimised and cached and you’re still pinned by real traffic, upgrading to a VPS with dedicated CPU is the correct move.
How is high CPU usage different from high memory or high disk usage? They’re three resources that fail in different ways. High CPU means the processor can’t keep up with the *work*, so requests queue and pages slow. High memory (RAM) means the server runs out of space for active data, causing swapping or out-of-memory errors. High disk usage — full storage or slow I/O — stalls reads and writes. They can trigger each other, but the symptoms and fixes differ, which is why you diagnose by looking at which resource is actually maxed out.
Conclusion
A pinned CPU sounds like an emergency and is really an invitation to look. The processor is fully occupied and work is queuing behind it — that’s the whole story, and it’s a readable one. Open top or htop on a VPS, or the resource-usage and process tools in cPanel on shared hosting, and the heaviest consumer names itself: a traffic spike, a heavy plugin, a slow query, a flood of bots, or a runaway cron. From there the fix follows the cause — cache to skip work, optimise to make work cheaper, block traffic that was never real, and tame scheduled jobs, measuring after each change.
And when you’ve done all that and the CPU is still pinned by legitimate, growing traffic, stop fighting the ceiling. That’s the moment shared CPU stops being enough and dedicated resources on a VPS become the calm, permanent answer. Diagnose first, optimise second, scale last.
