Is the Scheduler Overloaded?
When /proc/pressure/cpu shows an avg10 noticeably higher than its avg60, which is in turn higher than its avg300 — say, 20.5%, 8.3%, and 2.1% — that shape tells a story: there was a recent spike that is already fading. The system was briefly overloaded but is recovering.
The some value for CPU represents the percentage of time that at least one task was runnable — it had work to do and was not blocked on I/O or sleeping — but had to wait in the run queue because every CPU core was occupied. This is pure scheduler contention.
Practical thresholds (context-dependent):
some avg10 |
Interpretation |
|---|---|
| 0–5% | Healthy. Minimal scheduler contention. |
| 5–20% | Moderate. Latency-sensitive workloads will notice. |
| 20–50% | High. Significant performance degradation. Investigate. |
| 50%+ | Critical. The system is severely CPU-starved. |
PSI for CPU is fundamentally superior to "CPU Usage %" for diagnosing performance problems:
- CPU Usage 100% means you are fully utilizing your hardware. This is not inherently bad — it might mean your workload is perfectly sized.
- CPU Pressure 20% means you are over-utilizing it. Tasks are queuing. Your application is running slower than it would on a less loaded system. This is always bad.
A system can have 100% CPU usage and 0% CPU pressure (one perfectly CPU-bound process on one core, no contention). A system can also have 60% CPU usage and 40% CPU pressure (many short-lived tasks all competing for the same cores, causing constant context-switch overhead).
A common interview scenario: "Your service's CPU usage is at 70% and you're seeing latency spikes. Should you scale out?" The trap is saying "yes" based on utilization alone. The correct answer involves checking CPU pressure. If cpu.some is near zero, the 70% utilization is not causing scheduler contention — the latency spikes are coming from somewhere else (likely memory or I/O pressure, or a downstream dependency). Scaling out would waste money and not fix the problem.