CPU 100%: quick triage

In this guide: CPU 100%: quick triage. top/ps.

For troubleshooting, keep logs (`journalctl`) and basic network/port checks handy. Avoid heavy diagnostics on production unless you understand the impact.

If something goes wrong: check the service is running, listening on the expected port, and that your firewall allows the connection. For web services, `nginx -t` and `journalctl -u nginx` are good starting points. First identify the culprit process, then the cause (traffic, infinite loop, expensive queries).

If the issue appears only under load, account for concurrency limits, timeouts, and backpressure. A typical approach is to reduce concurrency, add retries with jitter, and observe where degradation starts.

Below you’ll find a quick checklist, verification commands, and common pitfalls. This helps you not only “do it”, but also confirm what a correct outcome looks like.

Quick checklist

• Collect logs/metrics before you start “fixing” things.
• Change one variable at a time and record the outcome.
• If it happens under load, check limits/timeouts.
• Make one small change at a time and verify the result immediately.
• Keep notes of what you changed (file/command/time).

Verify the result

# Verify / sanity checks
sudo journalctl -xe --no-pager | tail -n 120 || true
dmesg -T | tail -n 120 || true
sudo ss -lntup | head -n 80

Common pitfalls

• Fixing first and checking logs later (root cause is lost).
• Ignoring load/timeouts during bulk operations.

top
ps -eo pid,cmd,%cpu,%mem --sort=-%cpu | head -n 20