CPU at 100% is usually a code path, a runaway process, or a workload that has outgrown the host. The fix depends on the cause. Resizing the box is the most expensive and the least likely to address the actual problem.
Table of contents
- Find the process
- Profile it
- Look for the runaway
- Check the schedule
- Tune the code
- Resize the host
- FAQ
Find the process
The first step is to find the process that is using the CPU. On Linux:
toporhtopto see the live CPU usage by process.ps aux --sort=-%cpu | headto see the top CPU consumers.pidstat 1to see the per-CPU usage over time.
On Windows: Task Manager, Resource Monitor, or Get-Process | Sort-Object CPU -Descending.
Profile it
Once the process is identified, profile it. On Linux:
perf top -p <pid>for the live CPU profile.perf record -p <pid> -gfor the offline CPU profile, thenperf reportto read it.- For a Python process:
py-spy dump --pid <pid>for a stack trace of the running process. - For a Node.js process:
node --profandnode --prof-processto read the profile.
The profile shows the function that is consuming the CPU. The fix is usually in the application.
Look for the runaway
A runaway process is one that is using 100% CPU for no apparent reason. Common causes:
- An infinite loop. A
while (true)that does not break, a recursive function that does not terminate, a polling loop that does not have a backoff. - A leaking goroutine, thread, or worker. A goroutine that exits but does not clean up, leaving the next goroutine to do more work.
- A garbage collector in a tight loop. A JVM with a 2GB heap on a 1GB host, a Python process with a memory leak.
- A scheduler over-scheduling. A cron that runs every second instead of every minute, a heartbeat that fires every 10ms instead of every 1s.
Check the schedule
The CPU is at 100% because something is running on a schedule. Check the cron, the systemd timers, the Kubernetes cron jobs. The fix is usually to add a backoff, to batch the runs, or to run the heavy work asynchronously.
A useful pattern: every cron has a coalesce flag. If two crons run at the same time, they should merge into one. The team that has 10 crons running at midnight and 100% CPU is the team that does not have coalesce.
Tune the code
The fix is usually in the code:
- Add an index. A missing index can turn a 10ms query into a 10s query, and a 10s query into 10min.
- Cache the result. A cache hit is a 0.1ms response, a cache miss is a 100ms response.
- Batch the work. A single bulk insert is faster than 1000 single inserts.
- Compress the payload. A compressed payload is smaller, faster to send, and faster to parse.
- Stream the result. A streamed response is faster to start sending and uses less memory than a buffered response.
Resize the host
Resizing the host is the right answer when the workload genuinely needs more CPU. The test: profile the workload, find the function that is consuming the CPU, fix the function if possible, and if the function is already optimal, resize the host.
The trap: the team resizes the host, the CPU is still at 100%, and the team concludes “we need a bigger host.” The right conclusion is “we resized the wrong thing.” The bigger host has the same workload, the same code, the same runaway - just more cores to waste.
FAQ
Why is my server’s CPU at 100%?
Usually a code path (an infinite loop, a missing index, a slow query), a runaway process (a leaking goroutine, a tight GC loop), or a workload that has outgrown the host. Find the process, profile it, and the answer is usually in the code.
How do I find the process using the CPU?
On Linux: top, htop, ps aux --sort=-%cpu, or pidstat 1. On Windows: Task Manager, Resource Monitor, or Get-Process | Sort-Object CPU -Descending.
How do I profile a CPU-bound process?
On Linux: perf top -p <pid> for the live profile, or perf record -p <pid> -g for the offline profile. For Python: py-spy dump --pid <pid>. For Node.js: node --prof and node --prof-process.
Should I resize the host to fix CPU at 100%?
Only after the code path has been ruled out. Resizing the host before profiling is the most expensive mistake - the bigger host has the same workload, the same code, the same runaway.
What is the most common cause of CPU at 100%?
A missing index. A query that should be 10ms becomes 10s, and a query that should be 10s becomes 10min. The fix is in the database, not the host.
If you are sizing a server tier for a new project, the RunxBuild hosting calculator is the place to model the line items. The CPU, the memory, the storage, the I/O - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The RunxBuild dashboard is where the team sees the actual CPU usage in one place.