problem hub
Read-only, sensitive outputHigh CPU process on Linux
Rank CPU consumers and capture process context before killing or restarting a service.
Safest first command
ps -eo pid,ppid,stat,pcpu,pmem,comm,args --sort=-pcpu | headBefore you run this
Expected output: A process table sorted by CPU usage, including PID, parent PID, state, CPU, memory, command, and arguments.
When not to use it: Do not paste full process arguments publicly; they can include tokens, URLs, or credentials.
Expected output example
PID PPID STAT %CPU %MEM COMMAND ARGS
4242 1 R 98.5 4.1 node node server.js --port 3000How to read the result
High CPU identifies a suspect, not guilt. Compare parent process, command line, logs, recent deploys, and whether load average confirms pressure.
Rank first, then inspect
CPU ranking is a starting point. Capture PID and command line, then inspect service logs, request load, or recent deploys.
uptimeps -eo pid,ppid,stat,pcpu,pmem,comm,args --sort=-pcpu | head
Common causes
- Runaway worker or queue job
- Traffic spike
- Expensive request loop
- Backup/compression/indexing task
- Container workload consuming host CPU
What not to change yet
- Do not kill a process before identifying its service owner.
- Do not paste process arguments publicly.
- Do not restart a service without checking logs and recent deploys.
platform notes
Distro and service notes
Security
Process arguments can expose tokens, URLs, or customer data.
Containers
docker stats can show whether pressure comes from a container.
systemd
Use journalctl for the service after identifying the process.
supporting commands