SECURITY WARNING: Never run commands you don't understand. Always review code before execution. Use at your own risk.
Performance New Added 12 September 2026

Container CPU throttling: nr_throttled rising in cpu.stat

A CPU limit is enforced as a quota per 100ms period, so a process that spends its quota early is stopped until the period ends. Average utilisation looks comfortable while p99 latency spikes, which is why this gets blamed on the database or the network long before anyone reads cpu.stat.

Quick fix

Read the commands before running them. Anything that restarts a service, deletes data or changes permissions should be tried on a non-production system first.

Quick fix
# cgroup v2, from inside the container: throttled_usec is the answer
cat /sys/fs/cgroup/cpu.stat
# nr_periods, nr_throttled, throttled_usec

# cgroup v1
cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us /sys/fs/cgroup/cpu/cpu.cfs_period_us

# In Kubernetes the limit is the quota: 500m is half a core per period,
# not half a core on average, so a burst of parallel work throttles hard
kubectl get pod web-0 -o jsonpath='{.spec.containers[*].resources}'

# Prometheus, if node-exporter and cAdvisor are present
rate(container_cpu_cfs_throttled_periods_total[5m])
  / rate(container_cpu_cfs_periods_total[5m])

# Raise the limit, or remove it and keep the request: requests schedule,
# limits throttle. Runtimes that size thread pools from the host core count
# make this worse, so pin them: GOMAXPROCS, -XX:ActiveProcessorCount

How to diagnose Performance errors

Performance failures rarely produce an error message. They produce timeouts elsewhere. The three classic causes are stop-the-world garbage collection, thread pool starvation (all workers blocked on I/O so new requests queue), and event loop blocking in single-threaded runtimes. All three look identical from outside: latency climbs, then upstream timeouts fire. Distinguishing them requires looking inside the process.

If the quick fix above does not resolve it, work through these steps. They apply to this whole class of error, not just to this one message, which is usually what saves the time.

  1. Measure the p99, not the mean. Averages hide exactly the pauses that cause timeouts.
  2. For the JVM, enable GC logging (-Xlog:gc*) and correlate pause durations with latency spikes before tuning anything.
  3. For thread pools, log active versus queued task counts. A queue that grows while CPU is idle is starvation, and the fix is asynchronous I/O, not more threads.
  4. In Node.js, measure event loop lag directly (perf_hooks.monitorEventLoopDelay). Any synchronous work over a few milliseconds per request will show up here.
  5. Profile before optimising. pprof, async-profiler, py-spy and Chrome's profiler all point at the real hot path, which is rarely where intuition suggests.

Tools worth reaching for

  • async-profiler
  • go tool pprof
  • py-spy
  • perf_hooks.monitorEventLoopDelay
  • -Xlog:gc*

Authoritative references

Primary documentation for this error, worth reading before applying any fix in production.

kubernetes.io docs.kernel.org

Related Performance errors

See all 6 Performance errors →

Browse other categories

Something missing or wrong?

This entry is maintained by hand. If the fix is out of date, incomplete, or you have a better one, email a correction and it will be reviewed.