Inspecting Processes with ps, top, and htop

1. Start with a reproducible process inventory

ps is a snapshot tool. Its default output changes with options, environment, and implementation conventions, so operational scripts should request explicit columns. A useful inventory answers: who owns the process, when did it start, how long has it run, what state is it in, how much CPU and memory is attributed to it, what command is executing, and who is its parent?

# A stable, explicit process table.
ps -eo user:16,pid,ppid,stat,lstart,etime,pcpu,pmem,rss,vsz,comm,args \
  --sort=-pcpu | head -n 25

# Long-running processes first.
ps -eo pid,ppid,user,etime,stat,comm,args --sort=-etime | head -n 25

# Processes owned by the current user.
ps -u "$(id -un)" -o pid,ppid,stat,etime,pcpu,pmem,comm,args

# A parent-child forest when supported.
ps -eo pid,ppid,stat,comm,args --forest

Prefer numeric PIDs and explicit fields for machine processing. Do not parse decorative top output when ps, /proc, or a monitoring API provides a stable field.

2. Interpret process CPU and memory carefully

A large virtual size does not prove a leak, and a high RSS does not automatically indicate reclaim failure. Compare trends, application behavior, cgroup limits, system pressure, and workload volume. Process metrics are evidence—not verdicts.

3. top combines system and process views

top continuously refreshes load averages, task states, CPU categories, memory, swap, and a sortable process table. Use it to observe change: which processes rise when traffic starts, whether CPU time is user or system work, whether runnable tasks accumulate, and whether memory or swap pressure grows.

flowchart TB
  S["System summary: load, CPU, memory, swap"] --> Q{"Which resource is constrained?"}
  Q -->|CPU| C["Sort by CPU and inspect threads"]
  Q -->|Memory| M["Sort by RSS and inspect growth"]
  Q -->|I/O wait| I["Correlate with storage and blocked state"]
  Q -->|No pressure| B["Establish normal baseline"]
  C --> V["Verify with ps, /proc, logs, and service context"]
  M --> V
  I --> V

# Capture three non-interactive top samples, one second apart.
top -b -d 1 -n 3 | less

# Observe one PID only.
top -p "$$"

# Show threads for a target process in top.
top -H -p "$$"

Inside common top implementations, P sorts by CPU, M by memory, T by accumulated CPU time, 1 toggles per-CPU display, and H toggles threads. Check the on-screen help because key behavior can vary.

4. htop improves exploration, not measurement semantics

htop provides color, scrolling, tree views, searching, filtering, and easier column configuration. It is excellent for interactive exploration and teaching relationships. It may not be installed by default, and its display should not become your only incident evidence.

5. Process totals can hide one busy thread

Multithreaded runtimes may show aggregate process CPU while only one or a few threads are active. Use thread views to identify concentration, then correlate thread IDs with application diagnostics, stack traces, or runtime-specific tools.

pid=$$

# List threads as lightweight processes.
ps -L -p "$pid" -o pid,lwp,nlwp,psr,stat,pcpu,comm

# Alternative thread-oriented output.
ps -T -p "$pid" -o pid,spid,psr,stat,time,comm

# Count task directories exposed by procfs.
find "/proc/$pid/task" -mindepth 1 -maxdepth 1 -type d | wc -l

The thread ID is often called LWP, SPID, or TID depending on the tool. Do not assume that one sample proves sustained behavior; collect multiple samples over a meaningful interval.

6. Hands-on lab: compare idle and CPU-active snapshots

Create one controlled CPU workload, capture snapshots before and during execution, then terminate it cleanly. The loop runs at low priority and only under your account.

lab="$HOME/devops-academy/linux/chapter08/lesson02"
mkdir -p "$lab"

ps -eo pid,ppid,user,stat,etime,pcpu,pmem,rss,comm,args \
  --sort=-pcpu > "$lab/before.txt"

# Start a CPU loop at low priority.
nice -n 15 bash -c 'while :; do :; done' &
pid=$!
sleep 3

{
  printf 'captured_at=%s\n' "$(date --iso-8601=seconds)"
  printf 'target_pid=%s\n\n' "$pid"
  ps -o pid,ppid,ni,stat,etime,pcpu,pmem,rss,vsz,comm,args -p "$pid"
  printf '\n=== three top samples ===\n'
  top -b -d 1 -n 3 -p "$pid"
  printf '\n=== proc status ===\n'
  grep -E '^(State|Threads|VmRSS|VmSize|voluntary_ctxt_switches|nonvoluntary_ctxt_switches):' "/proc/$pid/status"
} > "$lab/during.txt"

kill -TERM "$pid"
wait "$pid" 2>/dev/null || true

ps -eo pid,ppid,user,stat,etime,pcpu,pmem,rss,comm,args \
  --sort=-pcpu > "$lab/after.txt"

less "$lab/during.txt"

7. Common mistakes

8. Knowledge check

9. Summary

ps provides reproducible snapshots; top and htop provide interactive change over time. Reliable process analysis uses explicit columns, repeated samples, thread awareness, and cautious interpretation of CPU, RSS, virtual memory, load, and state. Always connect process metrics to service expectations and system-level pressure.

10. Further reading

• ps(1), top(1), and htop(1).
• proc_pid_stat(5), proc_pid_status(5), and proc_loadavg(5).
• procps-ng documentation for process and system monitoring tools.