Monitoring Processes

Process monitoring is the act of reading the live process table — each task's state, CPU share, memory footprint, and parent/child relationships — to answer one question: what is running and what is it costing. The kernel keeps this table in memory and projects it through the /proc filesystem, where every running task has a directory named after its PID. Every tool here, from ps to htop, is a different way of reading and formatting those same files.

The operational consequence is the difference between a tool that snapshots and one that refreshes, and between columns that look alike but mean very different things. ps reads the table once; top and htop re-read it every 1.5 seconds by default. Read the memory columns wrong — VSZ as "memory used", or RSS summed across processes — and you will overstate real usage by gigabytes and chase the wrong problem at 2 a.m.

ps — the snapshot

ps prints one frozen view of the process table. It carries two historical syntaxes: BSD style, where options take no dash (ps aux), and UNIX style, where they do (ps -ef). Both list every process, but the column sets differ — aux shows %CPU, %MEM, VSZ, and RSS, while -ef shows the parent PID and start time. On Debian and Ubuntu both come from the procps package; the same binary behaves the same on RHEL-family hosts.

For scripts, the real power is -o, which names exactly the columns you want, and --sort, which orders output server-side. A sorted, custom-column snapshot is something you can drop straight into a ticket or a cron job without piping through sort.

# top memory consumers, custom columns, sorted descending
ps -eo pid,ppid,stat,vsz,rss,comm --sort=-rss | head
# filter to one program for a script
ps -C nginx -o pid,rss,etime

top — the live view

top ships with procps-ng and is present on essentially every Debian and Ubuntu host. It refreshes every 1.5 seconds by default (change it with -d), and the header reports the three load averages plus a task and CPU-state summary. Press Shift+P to sort by CPU, Shift+M to sort by memory, and k to send a signal to a PID without leaving the tool.

The summary line is where most misreadings happen. The CPU-state row breaks time into us (user), sy (system/kernel), id (idle), and wa (waiting on I/O); a high wa means the box is blocked on disk, not short of CPU. By default %CPU is per-core in Irix mode, so a single-threaded process can show 100% while seven other cores sit idle; toggle Shift+I to express it as a fraction of the whole machine.

htop — the practical default

htop is a separate package (apt install htop) and is the better interactive tool. It draws per-core meters, scrolls horizontally and vertically through the full table, supports incremental search with F3 and filtering with F4, and sends signals through a menu with F9 instead of asking you to remember signal numbers.

Its best feature for debugging is the tree view (F5), which lays out the parent/child hierarchy so you can see that a runaway worker belongs to a specific systemd unit or container, not floating free. Recent versions also group by cgroup, which makes "what is this container actually consuming" a glance rather than an investigation. btop and glances push the same idea further with graphs and historical sparklines.

Reading memory columns

Three memory figures appear across these tools, and they answer different questions. VSZ (VIRT in top) is the total virtual address space the process has mapped, including shared libraries it never faults in and memory it reserved but never touched. It routinely runs into gigabytes and almost never reflects real consumption.

RSS (RES) is the resident set — the pages actually present in physical RAM right now — and it is the number to read when asking how much memory a process occupies. The catch is shared pages: a process's RSS includes shared libraries like libc that are counted in every process's RSS, so summing RSS across processes double-counts that shared memory. For a true per-process figure that splits shared pages fairly, read PSS (proportional set size) from /proc/<pid>/smaps_rollup.

Column	Meaning	Read it for
VSZ / VIRT	Total virtual address space mapped	Almost never; it overstates real use
RSS / RES	Pages currently resident in RAM	A process's actual footprint
SHR	Resident pages shared with others	Estimating private vs shared memory
PSS	RSS with shared pages divided fairly	Summing memory across many processes

CPU% and load average

The %CPU column is a share measured since the last refresh, not a cumulative total, which is why it jumps around and why a single ps snapshot can miss a spike entirely. A momentary 90% during a refresh tick is meaningless; sustained 90% across a minute of top is the signal. Chase sustained usage, not a transient flicker.

Load average is the most misread number on the system. The three figures are the 1, 5, and 15-minute exponentially-weighted counts of tasks that are runnable or in uninterruptible (D-state) sleep — not a percentage. The reference point is core count: a load of 4.0 on a 4-core box means it is fully busy with no queue, while 4.0 on a single core means tasks are waiting three-deep. Because D-state I/O waits count, a load can climb past core count while CPUs sit idle behind a stuck disk.

# load average and core count side by side
cat /proc/loadavg
nproc