problem hub

Read-only, sensitive output

High 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 | head

Before 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 3000

How 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.

What to check next

One process is near a full core

Means: That PID is the first suspect, but it may be doing expected work.

Next step: Capture parent, state, and service context before killing or restarting it.

Find the Processes Burning CPU

Load average is high but no process tops ps

Means: The pressure may be short-lived, I/O wait, kernel work, or outside the current process view.

Next step: Read load average and compare it with CPU count and recent process snapshots.

Read Load Average Before You React

A container workload is the top consumer

Means: Host CPU pressure may map to a container rather than a host service.

Next step: Check one-shot container stats before restarting host services.

Snapshot Container CPU and Memory

Rank first, then inspect

CPU ranking is a starting point. Capture PID and command line, then inspect service logs, request load, or recent deploys.

uptime
ps -eo pid,ppid,stat,pcpu,pmem,comm,args --sort=-pcpu | head

Bad fixes to avoid

Do not kill the hottest PID before identifying the service owner, request pattern, and recent deploy context. Do not restart production workers just to lower the graph. Do not share full command lines when they may contain tokens, paths, or customer data.

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.

Stop and escalate if

The hot process is a database, queue worker, web app, backup, or migration job.
Killing or restarting it could lose work, corrupt state, or interrupt customers.
The load looks like abuse or an incident rather than normal application pressure.

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