A Linux host is reported to be pegged at high CPU, but `ps -eo pid,pcpu,args --sort=-pcpu | head` and `top -b -n1` both show no process above a few percent. Why do these two tools disagree with what the machine is doing right now?

## Percentages are always over some window A CPU percentage is meaningless without the interval it is measured over. Every one of these tools reads the same raw counters out of `/proc` — per-process CPU time in `/proc/<pid>/stat` and system-wide totals in `/proc/stat` — which are monotonically increasing tick counters. To turn a counter into a rate you must subtract two readings. The differences between the tools come entirely from *which* two readings they subtract. ## What ps computes `ps` takes one reading. For `%CPU` (field `pcpu`) it divides the process's accumulated CPU time by its elapsed wall-clock lifetime and expresses the ratio as a percentage. The manual page says exactly this, and it has two consequences worth stating in an interview: - **Old processes are diluted.** A database that has been up for 30 days and is right now burning a full core will report a small percentage, because one busy minute is invisible against 30 days of elapsed time. - **Young processes are inflated.** A build step that ran flat out for its entire three-second life shows close to 100% (or more on multiple cores) even though it is a rounding error in the machine's day. The consequence people find most surprising is that the `%CPU` column does not sum to anything meaningful. On an 8-core box the sum of `%CPU` across all processes can be far below 800 even while every core is saturated, because the busy processes are long-lived. ``` ps -eo pid,etimes,times,pcpu,args --sort=-times | head ``` Comparing `etimes` (elapsed seconds) with `times` (CPU seconds) makes the arithmetic visible: those two numbers are precisely what `%CPU` is the ratio of. ## What top computes, and what -n1 breaks `top` from procps-ng is built around repeated sampling. On each refresh it re-reads `/proc`, subtracts the previous reading, and divides by the delay, so its `%CPU` genuinely means "share of a CPU used since the last refresh". That is the number you want during an incident. Batch mode (`-b`) with a single iteration (`-n1`) removes the thing that makes it work. There is no previous sample, so the first output block cannot show a delta: the summary `%Cpu(s)` line reflects totals since boot, and the per-task percentages are lifetime figures of the same kind `ps` prints. A script that does `top -b -n1` to "see what is hot" is therefore reading history, not the present. The correct batch invocation asks for two iterations and discards the first: ``` top -b -n2 -d1 | awk '/^top -/{block++} block==2' ``` `-d1` sets a one-second delay, so the second block covers exactly that second. Other flags worth knowing: `-o %CPU` sets the sort field, `-H` shows individual threads rather than whole processes, `-p PID` restricts output to one process, `-c` toggles the full command line, and `-w` widens the output so long command lines are not clipped. ## The other reason the numbers look small: normalisation `top` defaults to what is historically called Irix mode, where `%CPU` is expressed relative to a single CPU — so a four-threaded process saturating four cores legitimately shows about 400%. Pressing `I` toggles Solaris mode, which divides by the number of CPUs and would report the same process as 100%. Confusing the two makes a busy process look either impossibly hot or oddly cool. `ps` does not offer that toggle; its ratio is single-CPU-relative too, which is why `%CPU` above 100 is possible there as well for a multithreaded process. ## How to answer this in practice The method is: never trust a single snapshot for a rate. Get an interval measurement — a second `top` sample, or `top` running interactively — and confirm it against the system-wide view before you name a process. If the interval measurement still shows no busy process, the CPU time is going somewhere the per-process view does not attribute cleanly: short-lived processes that are born and die between samples (a fork storm from a cron job or a health check), kernel threads, or interrupt and softirq time. Short-lived processes in particular are invisible to any sampling tool by construction — by the time the second sample is taken they are gone — and that is the point at which you stop sampling and reach for a tool that hooks process creation instead. ## What to say about the trap The interviewer is checking whether you know that a percentage has a denominator. If you can state that `ps` divides by lifetime and `top` divides by the interval between two samples — and that `-n1` leaves top with no interval — you have answered the question.