Monitoring Processes with ps and top
Every running program on a Linux system is represented by a process, and understanding what is running, how much CPU and memory it consumes, and what state it's in is fundamental to system administration. The ps command takes a point-in-time snapshot of processes, while top (and its modern successor htop) provides a continuously refreshing, interactive view. Together they form the primary toolkit for answering 'what is my system doing right now, and why is it slow?'
Cricket analogy: ps is like a single freeze-frame photo of the scoreboard at one moment; top is like watching the live scoreboard refresh ball by ball — together they answer "what's happening in this match right now, and why has the run rate stalled?"
ps: the process snapshot
ps by itself, with no options, only shows processes attached to your current terminal session — usually just your shell and the ps command itself. To see the whole system you need option combinations. The BSD-style ps aux and the UNIX-style ps -ef are the two most common invocations, and while they originate from different standards they both work on Linux because GNU ps supports both syntaxes. aux shows all processes (a), including those without a controlling terminal (x), in user-oriented format (u) with the owning username; -ef shows every process (-e) in full format (-f) with parent PID included, which is handy for tracing process trees.
Cricket analogy: Plain ps only shows your own team's dugout, not the whole stadium; ps aux shows all players (a) including support staff off-camera (x) with names labeled (u), while ps -ef is the same full stadium view (-e) with coaching lineage shown (-f) — different broadcasters, same ground, both valid.
# BSD-style: all processes, user format
ps aux | head -20
# UNIX-style: full listing with parent PIDs
ps -ef | grep nginx
# Show a process tree (who spawned whom)
ps -ef --forest
# or, more compact:
ps auxf
# Custom columns: PID, %CPU, %MEM, elapsed time, command
ps -eo pid,pcpu,pmem,etime,cmd --sort=-pcpu | head -10
# Threads for a specific process
ps -eLf | grep 1234Reading the columns
Key ps aux columns: USER (owner), PID (process ID), %CPU (recent CPU usage, can exceed 100% on multi-core systems if a process uses several threads), %MEM (resident memory as a percentage of physical RAM), VSZ (virtual memory size in KB), RSS (resident set size — actual physical RAM in use), TTY (controlling terminal, or ? if none), STAT (process state code), START (start time), and TIME (cumulative CPU time consumed, not wall-clock time). The STAT column uses codes such as R (running or runnable), S (interruptible sleep, waiting for an event), D (uninterruptible sleep, usually waiting on disk I/O and cannot be killed with SIGKILL until the I/O completes), Z (zombie — terminated but not yet reaped by its parent), and T (stopped, e.g. by SIGSTOP or Ctrl+Z). A trailing + means the process is in the foreground process group of its terminal.
Cricket analogy: In a scorecard, USER is the batsman's name, PID their unique cap number, %CPU their current strike rate, %MEM their share of team runs, TTY which ground they're playing at; STAT codes mirror match states — R for actively batting, S for waiting in the pavilion for a partnership, D for stuck on a DRS review that can't be interrupted, Z for a retired-out batsman not yet removed from the card, and T for a rain-delayed player.
top: the interactive monitor
top refreshes its display every few seconds (3 by default) and lets you sort, filter, and act on processes without leaving the screen. The header summarizes uptime and load averages, task counts by state, overall CPU usage broken into user/system/nice/idle/wait time, and memory/swap totals. Inside top, pressing P sorts by CPU usage, M sorts by memory usage, k prompts for a PID to kill, r renices a process, 1 toggles per-core CPU breakdown, and q quits. The load average figures (e.g. '0.52, 0.75, 0.91') represent the average number of processes wanting CPU time over the last 1, 5, and 15 minutes — on a system with 4 cores, a sustained load average above 4 indicates processes are queuing for CPU.
Cricket analogy: top refreshing every few seconds is like a live scoreboard updating each ball; pressing P sorts batsmen by strike rate, M sorts by total runs, k retires a batsman, r adjusts a bowler's over allocation, 1 shows each pitch condition, and q returns to the pavilion; the load average is like the overs still queued over the last 1, 5, and 15 overs — too many queued overs on a 4-bowler attack means it's overloaded.
# Launch top, sorted by memory by default
top -o %MEM
# Batch mode: one snapshot, useful for scripting/logging
top -b -n 1 | head -15
# Show only a specific user's processes
top -u www-data
# htop is usually a separate package (more readable, mouse support)
sudo apt install htop # Debian/Ubuntu
sudo yum install htop # RHEL/CentOSThe %CPU figure in both ps and top can legitimately exceed 100% on multi-core machines because it represents the sum of CPU time across all cores a process's threads are using — a process with 4 busy threads on a 4-core box can show close to 400%. Don't mistake this for a bug.
A process stuck in D state (uninterruptible sleep) cannot be killed with kill -9 — it is blocked inside a kernel operation, typically slow or failing disk/NFS I/O, and will only exit once that operation completes or times out. Repeated D-state processes are a strong signal of a storage subsystem problem, not an application bug.
ps aux(BSD style) andps -ef(UNIX style) both list all system processes; combine with--sortor custom-eocolumns for targeted views.- STAT codes matter: R=running, S=sleeping, D=uninterruptible I/O wait, Z=zombie, T=stopped.
- %CPU can exceed 100% on multi-core systems since it sums usage across all threads/cores.
topis a live, interactive view; press P/M to sort by CPU/memory, k to kill, q to quit.- Load average (1/5/15 min) approximates demand for CPU time; compare it against the core count, not against 1.0.
htopis a friendlier, usually separately installed alternative totopwith color and mouse support.
Practice what you learned
1. In `ps aux` output, which column shows the actual physical RAM a process currently occupies?
2. A process shown with STAT 'D' in ps is:
3. Why might `top` show a process using 250% CPU?
4. Which command produces a single non-interactive snapshot of top's output, suitable for logging in a script?
5. What does a load average of 8.0 mean on a machine with 4 CPU cores?
Was this page helpful?
You May Also Like
Killing and Signaling Processes
Understand Unix signals and the kill, killall, and pkill commands to gracefully terminate or forcibly stop misbehaving processes.
Understanding Processes
Learn what a process is in Linux, how it relates to programs and the kernel, key attributes like PID/PPID and process states, and the parent-child process tree.
Background Jobs and nohup
Learn to run and manage background jobs with &, jobs, bg/fg, and disown, and keep long-running processes alive after logout using nohup and disown.
systemd and Managing Services
Learn how systemd manages services, sockets, and timers as units, and how to start, stop, enable, and inspect them with systemctl and journalctl.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsDocker & Kubernetes Study Notes
YAML · 40 topics