Inspect CPU and processes

When a machine feels slow, collect evidence before killing the busiest process or rebooting everything.

Start with a system-level view:

uptime
top

uptime shows load averages for roughly the last 1, 5, and 15 minutes. Load is not the same as CPU percentage. It includes runnable work and some tasks waiting on uninterruptible operations such as disk I/O.

Compare load with the number of CPU cores:

nproc

A load of 4 means something different on a 2-core machine and a 32-core machine.

Capture a repeatable process snapshot

Use ps when you want output you can sort and save:

ps -eo pid,ppid,user,stat,%cpu,%mem,etime,comm --sort=-%cpu | head

Look at elapsed time, process state, CPU, memory, owner, parent, and recent service logs together. A short CPU spike during a build is normal. A worker consuming one core continuously after every request may need investigation.

Find the service behind a process before acting:

systemctl status 1234

Systemd can often map a PID to its unit. If not, inspect /proc/1234 or the process command line without exposing secrets.

Stop gracefully first

For a managed service, prefer its service command:

sudo systemctl stop notes-api

For an individual process, ordinary kill PID sends SIGTERM, giving the program a chance to close files and connections.

Use kill -KILL PID only when the process cannot respond. SIGKILL cannot be handled, so cleanup code does not run. Killing a database or writer this way can require recovery.

Verify the result

Confirm that the intended process stopped, system pressure changed, and the application recovered. Then find the cause. Restarting a leaking process restores capacity temporarily but does not fix the leak.

Try this: run one harmless CPU-intensive command on a test system. Find its PID with ps, inspect its elapsed time and state, then stop it with SIGTERM.