Linux commando: top

1. De basis

top laat je een lijst met processen zien, gesorteerd op CPU-gebruik, elke paar seconden ververst, met daarboven een samenvatting van de hele machine. Dat is het hele idee. Alles wat de moeite waard is zit in wat die getallen werkelijk betekenen, want een aantal ervan betekent iets heel anders dan het lijkt.

1.1 De eenvoudigst mogelijke toepassing

Typ de naam, verder niets:

$ top

Het scherm wordt leeggemaakt en vult zich met een vaste indeling. Druk op q om te stoppen, of op h voor hulp. Dat zijn de enige twee toetsen die je vooraf moet kennen.

top - 17:21:38 up  6:11,  1 user,  load average: 1.63, 1.39, 1.29
Tasks: 517 total,   2 running, 515 sleeping,   0 stopped,   0 zombie
%Cpu(s):  4.7 us,  2.6 sy,  0.0 ni, 92.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :  64026.3 total,  34464.3 free,  14897.2 used,  16868.6 buff/cache
MiB Swap:   8192.0 total,   8192.0 free,      0.0 used.  49129.1 avail Mem

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 118289 pe7er     20   0 1448.5g 557844 260284 R  91.7   0.9   1:42.29 chrome
  10681 pe7er     20   0   10.6g   3.7g   1.3g S  16.7   5.9  87:49.77 phpstorm
 106453 pe7er     20   0 1448.4g 251576 157480 S   8.3   0.4  16:10.38 chrome
 120269 pe7er     20   0   14868   5584   3536 R   8.3   0.0   0:00.02 top
      1 root      20   0   24500  15008   9248 S   0.0   0.0   0:04.40 systemd

Alle uitvoer in dit artikel komt van die machine: zestien CPU-kernen, 62,5 GiB geheugen, Ubuntu, top uit procps-ng 4.0.4.

1.2 De vijf samenvattingsregels

Het blok bovenaan beschrijft de machine, niet een afzonderlijk proces. Elke regel heeft zijn eigen schakeltoets, en elke regel wordt op zijn eigen manier verkeerd gelezen.

1.3 De kolommen van de processenlijst

Onder de kop komt een regel per proces. Dit zijn de standaardkolommen:

De toestandsletters komen voortdurend langs in supportgesprekken, dus het loont om ze goed te kennen:

R   running, or ready to run and waiting for a CPU
S   sleeping, waiting for something that can be interrupted
D   uninterruptible sleep, nearly always waiting for disk or network storage
I   idle kernel thread
T   stopped by a job control signal (Ctrl-Z)
t   stopped by a debugger
Z   zombie: finished, but its parent has not collected the exit status

D is de interessante. Een proces in D kun je niet afbreken, zelfs niet met kill -9, omdat het midden in een kernelaanroep zit die nog niet is teruggekeerd. Het telt bovendien mee in de load average, en daar begint de meeste verwarring over dat getal.

1.4 Het mentale model

Een zin verklaart bijna elke verrassing in dit artikel.

top bemonstert. Elk veld met een procentteken is een verschil tussen twee metingen, genomen over het verversingsinterval. Elk veld zonder procentteken is een totaal, opgebouwd sinds het proces startte of sinds de opstart.

Daarom kunnen %CPU en TIME+ zo hevig met elkaar in tegenspraak zijn. TIME+ zegt dat een proces sinds dinsdag negentig minuten CPU heeft gebruikt. %CPU zegt dat het in de laatste drie seconden niets gebruikte. Allebei waar, en ze beantwoorden verschillende vragen.

Het verklaart ook waarom het allereerste scherm anders is dan de schermen erna, en waarom een script dat top een keer draait een antwoord krijgt dat het niet moet vertrouwen. Paragraaf 6.2 meet precies hoe erg dat is.

3. Een korte geschiedenis

De Linux-top stamt niet af van die van LeFebvre. Het is een herimplementatie die de naam, de indeling en het ritme van drie seconden overnam en daarna zijn eigen weg ging. De tweede helft van dat verhaal lees je in het copyrightbestand op elke Debian- of Ubuntu-machine:

$ grep -B1 -A1 "James C. Warner" /usr/share/doc/procps/copyright
Files: src/top/*
Copyright: 2002-2022 James C. Warner
License: LGPL-2.0+

Daar volgen twee praktische gevolgen uit, en mensen lopen er allebei tegenaan.

Ten eerste: top zit niet in POSIX en heeft daar nooit in gezeten. Er is geen standaard voor, dus er is geen enkele garantie dat de opties uit jouw aantekeningen op de volgende machine werken. Op FreeBSD of macOS krijg je een afstammeling van de versie van LeFebvre, met een eigen set opties en eigen veldnamen. In een minimale containerimage krijg je vaak BusyBox-top, alweer een derde implementatie met een compleet andere uitvoer. Controleer wat je werkelijk draait voordat je op een optie vertrouwt, en lees de lokale handleiding in plaats van een die je online vond:

$ top -V
top from procps-ng 4.0.4

Ten tweede: er zijn echt steeds opties bij gekomen. -E, -e, -O en de lange vormen zijn recent. Een server van vijf jaar oud heeft ze misschien niet, en een handleiding uit 2015 beschrijft mogelijk een programma dat zich inmiddels anders gedraagt.

5. Gemiddelde toepassingen

5.1 Een kern volledig bezet, vijftien niets doen

De %Cpu(s)-regel is een gemiddelde, en gemiddelden verbergen precies het probleem waar je meestal naar op zoek bent. Een proces met een thread dat een kern volledig bezet houdt op een machine met zestien kernen kan het gemiddelde maar met 6 procent laten stijgen, dus de kop ziet er rustig uit terwijl een kern in brand staat.

Druk op 1. Dat splitst die ene regel op in een regel per kern. Hier is een machine met een enkele bezige lus, op beide manieren bekeken:

# the default, combined view
%Cpu(s): 16.2 us,  0.7 sy,  0.0 ni, 83.0 id,  0.0 wa,  0.0 hi,  0.2 si,  0.0 st

# after pressing 1
%Cpu0  :  3.0 us,  1.0 sy,  0.0 ni, 96.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  :  5.1 us,  1.0 sy,  0.0 ni, 93.9 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu2  :  3.0 us,  1.0 sy,  0.0 ni, 96.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  : 98.0 us,  0.0 sy,  0.0 ni,  2.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu4  :  3.0 us,  1.0 sy,  0.0 ni, 96.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
...
%Cpu15 :  5.0 us,  1.0 sy,  0.0 ni, 94.1 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st

Zestien procent in de samenvatting. Achtennegentig procent op kern 3. Dit is de handtekening van een knelpunt met een enkele thread, en het is een van de nuttigste dingen die top je kan laten zien: een PHP-script, een cron-taak of een databasequery die niet over kernen verdeeld kan worden, hoeveel je er ook bijkoopt.

Op een machine met veel kernen passen de regels per kern niet allemaal. 4 zet meerdere CPU's op elke regel, en ! voegt ze samen per twee, dan per vier, dan per acht. -1 op de commandoregel start met de schakelaar al omgezet.

5.2 De kernen die een proces niet mag gebruiken

Paragraaf 5.1 liet een proces zien dat maar een kern kon gebruiken omdat het maar een thread had. Er is een tweede reden waarom een druk proces vijftien vrije kernen negeert, en die is onzichtbaar in elke kolom die top standaard toont: het proces mag er misschien niet op draaien.

Linux laat je een taak vastzetten op een deel van de CPU's. taskset leest dat masker en stelt het in:

$ taskset -cp 130667                 # -c for a CPU list, -p for an existing pid
pid 130667's current affinity list: 2

$ taskset -c 0,1 ./import.sh         # start something on CPUs 0 and 1 only
$ taskset -cp 0-3 130667             # move a running process onto CPUs 0 to 3

Een bezige lus die vastgezet is op CPU 2 ziet er in de processenlijst volstrekt normaal uit. Hij gebruikt een hele kern, en top zegt dat ook:

$ top -b -n 2 -d 1 -p 130667 | tail -1
 130667 pe7er     20   0   10308   3508   3252 R  99.0   0.0   0:12.48 bash

Druk op 1 en de beperking wordt zichtbaar. Een kern draait op volle toeren en zijn buren slapen, en geen enkele hoeveelheid vrije capaciteit elders helpt daarbij:

%Cpu1  :  1.7 us,  0.0 sy,  0.0 ni, 98.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu2  :100.0 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  :  2.3 us,  0.6 sy,  0.0 ni, 97.2 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
...

Dat beeld is identiek aan dat van de enkele thread in paragraaf 5.1, en juist daarom is het de moeite waard om dit te weten. De twee oorzaken zien er op het scherm hetzelfde uit en hebben totaal verschillende oplossingen: de applicatie van threads voorzien, of de vastzetting weghalen. taskset -cp is het ene commando dat ze uit elkaar houdt.

Affiniteit wordt zelden per ongeluk ingesteld, maar vaak wel ingesteld en daarna vergeten. De gebruikelijke bronnen op een server:

top kan je laten zien op welke kern een taak het laatst draaide. Zet het veld P aan met f, en kijk hoe het stil blijft staan bij een vastgezet proces en rondzwerft bij een normaal proces. De handleiding geeft een eerlijke waarschuwing bij die kolom: "the very act of running top may break this weak affinity and cause more processes to change CPUs more often".

Een onderscheid om goed te onthouden, want deze twee worden voortdurend verward. Affiniteit zegt waar een taak mag draaien. Een CPU-quotum van een cgroup, zoals een container dat krijgt, zegt hoeveel hij mag draaien, zonder hem tot bepaalde kernen te beperken. Een proces kan afgeknepen worden tot een halve CPU en toch over alle zestien kernen ingepland worden. Paragraaf 7.1 behandelt wat top daarvan wel en niet kan zien.

5.3 Een %CPU van 400 is geen fout

Standaard draait top in wat de handleiding Irix-modus noemt, waarin 100 procent een volledig bezette kern betekent. Een proces met vier bezige threads toont daarom 400. Dit is een compressietaak met vier werkthreads:

$ top -b -n 2 -d 1 -p 123850 | tail -1
 123850 pe7er     20   0  372564  70144   2304 S 401.0   0.1   0:16.83 xz

Druk op H (kort voor threads-show) en hetzelfde proces valt uiteen in zijn threads, elk met een eigen regel en een eigen aandeel:

$ top -b -n 2 -d 1 -H -p 123850 | tail -5
 123852 pe7er     20   0  372564  70144   2304 R  99.9   0.1   0:05.40 xz
 123853 pe7er     20   0  372564  70144   2304 R  99.9   0.1   0:05.39 xz
 123854 pe7er     20   0  372564  70144   2304 R  99.9   0.1   0:05.39 xz
 123855 pe7er     20   0  372564  70144   2304 R  99.9   0.1   0:05.39 xz
 123850 pe7er     20   0  372564  70144   2304 S   1.0   0.1   0:00.05 xz

Vier threads op 100 procent en een ouderproces dat de coördinatie doet. De 401 was nooit mysterieus; het waren vier kernen plus afronding.

Dat is het antwoord dat je wilt als een proces op 100 procent blijft steken en niet hoger komt: is het een verzadigde thread, of veertig threads die elk een beetje doen? Twee commando's buiten top beantwoorden dat prettiger, en allebei laten ze zien op welke CPU elke thread het laatst draaide:

$ ps -L -p 130929 -o pid,tid,psr,pcpu,comm
 130929  130929   4  0.6 xz            # the parent, idle
 130929  130931   6  102 xz            # tid, psr = which core, pcpu
 130929  130932   3  102 xz
 130929  130933   2  102 xz

$ pidstat -t -p 130929 1 1
Average:  1000  130929       -  300.00  1.00 ...   xz
Average:  1000       -  130931  100.00  0.00 ... |__xz
Average:  1000       -  130932  100.00  0.00 ... |__xz
Average:  1000       -  130933  100.00  0.00 ... |__xz

pidstat -t is de duidelijkste van de twee: hij drukt het totaal van het proces op een regel af en zet elke thread daaronder ingesprongen. Drie threads op 100 met een totaal van 301 is een gezonde parallelle taak. Een thread op 100 met een totaal van 101, bij een proces met veertig threads, is een knelpunt met een naam.

Als je de andere afspraak prettiger vindt, schakelt I over naar de Solaris-modus, die deelt door het aantal kernen zodat 100 procent de hele machine betekent. Hetzelfde proces, een toetsaanslag later:

Irix mode Off
 123978 pe7er     20   0  372564  70272   2304 S  25.1   0.1   0:25.04 xz

401 gedeeld door zestien kernen is 25,1. Geen van beide getallen is fout; ze beantwoorden verschillende vragen. De Irix-modus vertelt je hoeveel kernen een proces gebruikt, de Solaris-modus vertelt je welk deel van de machine het gebruikt. Weet welke van de twee je bekijkt voordat je iemand een getal noemt, want I is een blijvende schakelaar en een collega kan hem omgezet hebben.

5.4 Minder tonen

Vijfhonderd regels die voorbijschuiven is geen diagnose. top heeft drie aparte manieren om de lijst te versmallen, en ze gedragen zich verschillend.

-u (kort voor filter-only-euser) kijkt naar de effectieve gebruiker; -U (kort voor filter-any-user) kijkt naar de echte, effectieve, opgeslagen of bestandssysteemgebruiker. Zet er ! voor om het om te keren:

$ top -u www-data           # only the web server's processes
$ top -u mysql              # only the database
$ top -U '!root'            # everything that is not root

-p (kort voor pid) volgt specifieke processen, tot twintig stuks:

$ top -p 1234,5678
$ top -p $(pgrep php-fpm | head -20 | paste -sd,)     # the 20-pid limit, safely

En interactief bouwen o en O een filter op werkelijk elk veld. De syntaxis is een veldnaam, een operator en een waarde:

o     then type    COMMAND=chrome       only chrome processes (case ignored)
O     then type    RES>500000           only processes above ~500 MiB resident
o     then type    !USER=root           everything except root
^O                                      show which filters are active
=                                       clear all filters in this window

Nu de valkuil, en die overkomt iedereen een keer. Het filteren van de processenlijst filtert de samenvatting niet. Met een filter dat alleen chrome toont, telt de kop nog steeds de hele machine:

$ top -b -n 1 -u root | sed -n '2p'
Tasks: 515 total,   1 running, 514 sleeping,   0 stopped,   0 zombie

$ top -b -n 1 -u root | tail -n +8 | wc -l
305                              # only 305 root processes are listed

515 in de kop, 305 in de lijst. De enige uitzondering is -p, die het aantal wel beperkt, dus een gefilterde Tasks:-regel betekent dat je -p gebruikte en verder niets. Noem nooit een getal uit de samenvatting van een gefilterd scherm.

5.5 Zien wat een proces werkelijk is

COMMAND toont standaard de programmanaam, wat nutteloos is als twintig regels allemaal php-fpm zeggen. c (ook beschikbaar als -c, kort voor cmdline-toggle) vervangt dat door de volledige commandoregel:

$ top -b -n 1 -c -w 200 -o +%MEM | sed -n '8p'
  10681 pe7er     20   0   10.6g   3.8g   1.3g S  45.5   6.0  89:33.95 /home/pe7er/.local/share/JetBrains/Toolbox/apps/phpstorm/bin/phpstorm

Kernelthreads hebben geen commandoregel, dus die verschijnen tussen vierkante haken: [kthreadd], [kworker/0:0H]. Zo herken je in een oogopslag een kernelthread, en kernelthreads tonen altijd 0 bij VIRT, RES en SHR.

V zet de boomweergave aan, die de lijst ordent op ouderschap en de boom tekent:

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
    871 root      19  -1   84512  22256  21092 S   0.0   0.0   0:02.22  `- systemd-journal
    987 root      20   0   31520   9372   5148 S   0.0   0.0   0:00.51  `- systemd-udevd
   1743 systemd+  20   0   17564   7528   6760 S   0.0   0.0   0:09.54  `- systemd-oomd
   1749 systemd+  20   0   21872  13264  11088 S   0.0   0.0   0:03.22  `- systemd-resolve
   1977 avahi     20   0   11544   6396   3836 S   0.0   0.0   1:34.01  `- avahi-daemon
   2108 avahi     20   0    8480   1440   1164 S   0.0   0.0   0:00.00      `- avahi-daemon
   1985 root      20   0   13692   6328   6072 S   0.0   0.0   0:00.19  `- bluetoothd

Zo ontdek je dat het mysterieuze proces dat CPU opat door een cron-taak was afgesplitst en niet door de webserver. v klapt de kinderen van het bovenste proces in of uit, en elke sorteertoets verlaat de boomweergave, wat handig is om te weten voordat je je afvraagt waar je boom gebleven is.

5.6 De kolommen veranderen, en die verandering bewaren

f opent het veldbeheer. Met de pijltjestoetsen navigeer je, d of de spatiebalk zet een veld aan of uit, s maakt het het sorteerveld, en q gaat terug. Er zijn ruim zeventig velden beschikbaar, veel meer dan het tiental dat standaard getoond wordt:

$ top -O | tr '\n' ' '
PID PPID UID USER RUID RUSER SUID SUSER GID GROUP PGRP TTY TPGID SID PR NI nTH P
%CPU TIME TIME+ %MEM VIRT SWAP RES CODE DATA SHR nMaj nMin nDRT S COMMAND WCHAN
Flags CGROUPS SUPGIDS SUPGRPS TGID OOMa OOMs ENVIRON vMj vMn USED nsIPC nsMNT
nsNET nsPID nsUSER nsUTS LXC RSan RSfd RSlk RSsh CGNAME NU LOGID EXE RSS PSS
PSan PSfd PSsh USS ioR ioRop ioW ioWop AGID AGNI STARTED ELAPSED %CUU %CUC ...

Een handjevol daarvan is het waard om aan te zetten voor echt werk:

Alles wat je verandert blijft gelden tot je stopt, tenzij je op W drukt. Dat schrijft een configuratiebestand en meldt waar het terechtkwam:

W

Wrote configuration to '/home/pe7er/.config/procps/toprc'

De oude locatie was ~/.toprc, met een punt ervoor, en die wordt nog steeds gehonoreerd. De naam volgt eigenlijk de naam van het programma, dus een alias die t heet leest en schrijft procps/trc. Het bestand legt het sorteerveld vast, de zichtbare kolommen, de kleuren, de vertraging en de stand van elke schakelaar:

$ head -2 ~/.config/procps/toprc
top's Config File (Linux processes with windows)
Id:k, Mode_altscr=0, Mode_irixps=1, Delay_time=1.0, Curwin=0

Let op Delay_time=1.0 daar, bewaard uit een sessie die met -d 1 was gestart. Die ene regel heeft gevolgen die veel verder reiken dan het interactieve scherm, en dat is paragraaf 6.3.

7. Iets wat de meeste gebruikers niet weten

7.1 In een container rapporteert top de host

Deze kost echte tijd en echt geld, want hij zorgt ervoor dat mensen containers dimensioneren op een getal dat nooit over hun container ging.

Dit is top die draait in een container met een harde limiet van 256 MiB geheugen en een CPU:

$ docker run --rm -m 256m --cpus 1 mariadb:10.6.18 sh -c 'top -b -n 1 | head -5'
top - 15:28:56 up  6:18,  0 users,  load average: 2.52, 1.67, 1.43
Tasks:   3 total,   1 running,   2 sleeping,   0 stopped,   0 zombie
%Cpu(s): 25.4 us,  3.0 sy,  0.0 ni, 71.6 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :  64026.3 total,  34062.5 free,  12709.0 used,  17254.8 buff/cache
MiB Swap:   8192.0 total,   8192.0 free,      0.0 used.  49266.0 avail Mem

62,5 GiB in totaal. De container mag 256 MiB gebruiken. En die limiet geldt echt:

$ docker run --rm -m 256m --cpus 1 mariadb:10.6.18 sh -c \
      'cat /sys/fs/cgroup/memory.max; cat /sys/fs/cgroup/cpu.max; nproc'
268435456                          # 256 MiB, exactly as requested
100000 100000                      # one CPU's worth of quota
16                                 # but the machine still looks like 16 cores

Kijk wel naar de regel Tasks: 3 total, want die laat zien wat er aan de hand is. De PID-namespace wordt gerespecteerd, dus top ziet alleen de drie processen in de container. De cgroups voor geheugen en CPU niet, want top leest /proc/meminfo en /proc/stat, en dat zijn de bestanden van de host, rechtstreeks doorgekoppeld.

In een container vertelt top dus de waarheid over processen en liegt hij over capaciteit. De load average is die van de host. De CPU-percentages zijn aandelen van alle zestien kernen van de host. Het geheugentotaal is het RAM van de host, wat betekent dat %MEM een breuk met de verkeerde noemer is: een proces op 90 procent van zijn containerlimiet verschijnt als 0,4 procent.

Als je de eigen getallen van de container nodig hebt, lees dan de cgroup-bestanden of vraag het de runtime:

$ cat /sys/fs/cgroup/memory.current   /sys/fs/cgroup/memory.max
$ cat /sys/fs/cgroup/cpu.stat
$ docker stats --no-stream          # from the host: real per-container figures

Die PID-namespace heeft nog een tweede gevolg, en dat bijt op het moment dat je iets wilt doen met wat je zag. Een PID betekent alleen iets binnen de namespace waarin je hem las. Hetzelfde proces heeft een nummer in de container en een ander nummer op de host:

$ C=$(docker run -d --rm -m 256m mariadb:10.6.18 sleep 120)

# inside the container:
$ docker exec $C ps -eo pid,comm
    PID COMMAND
      1 sleep

# on the host, the very same process:
$ docker inspect -f '{{.State.Pid}}' $C
130140

Een PID die je uit de top van een container overneemt is dus betekenisloos in de top van de host, en hoort daar heel goed bij iets heel anders. Erger nog: een kill 1 die de applicatie van een container zou stoppen, is op de host gericht op systemd. Bepaal aan welke kant je staat voordat je handelt, en gebruik docker inspect of docker top om tussen de twee te vertalen.

Dezelfde waarschuwing geldt voor free, uptime en nproc. Het is geen fout in top; het is wat er gebeurt als een programma dat voor hele machines is geschreven in een plakje van een machine draait.

7.2 Je kunt RES niet optellen

RES is het eerlijke geheugengetal per proces, en de voor de hand liggende volgende stap is de kolom optellen om te zien waar het RAM heen ging. Dat werkt niet, en de fout is groot.

$ ps -eo rss= | awk '{s+=$1} END {printf "sum of RES over all processes: %.1f MiB\n", s/1024}'
sum of RES over all processes: 23660.6 MiB

$ top -b -n 1 | sed -n 4p
MiB Mem :  64026.3 total,  33770.9 free,  15078.0 used,  17595.8 buff/cache

23,6 GiB aan RES tegenover 15,0 GiB die werkelijk in gebruik is. De som is ruim anderhalf keer te groot, en op een machine die veel kopieën van hetzelfde programma draait is het gat veel erger.

De oorzaak is delen. Gedeelde bibliotheken, het programma-image zelf, copy-on-write-pagina's die van een fork zijn geerfd, gedeelde geheugensegmenten: elke pagina wordt volledig geteld bij elk proces dat hem koppelt. Twintig PHP-FPM-workers die van een ouderproces zijn afgesplitst rapporteren allemaal het geheugen van de ouder als het hunne. De kolom SHR vertelt je ruwweg hoeveel van RES het risico loopt dubbel geteld te worden, en daarom staat SHR er direct naast.

Als je een getal nodig hebt dat wel optelt, vraag dan om de proportional set size, waarbij elke gedeelde pagina wordt gedeeld door het aantal processen dat hem deelt:

PSS    proportional set size: shared pages divided by the number of sharers
USS    unique set size: the pages this process alone holds
RSS    a more precise resident figure, from smaps_rollup

Alle drie zijn in top beschikbaar via f, en de handleiding en de werkelijkheid zijn het eens over de prijs: "Accessing smaps values is 10x more costly than other memory statistics", en om ze voor de processen van een andere gebruiker te lezen heb je root nodig. Zet ze aan als je geheugen onderzoekt, en zet ze daarna weer uit.

De praktische regel: gebruik RES om processen met elkaar te vergelijken, en de samenvattingsregel om te vragen hoeveel geheugen de machine gebruikt. Leid nooit het een uit het ander af.

7.3 VIRT betekent bijna niets

Het breedste getal op het scherm is het getal waar je je het minst druk om hoeft te maken:

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 106453 pe7er     20   0 1448.4g 251576 157480 S  16.7   0.4  16:48.36 chrome

1448,4 gibibyte virtueel geheugen, op een machine met 62,5 GiB RAM en 8 GiB swap. Dat is ongeveer twintig keer meer geheugen dan er ergens op die machine bestaat, en er is niets mis.

VIRT is adresruimte, geen geheugen. Het telt alles wat het proces heeft gekoppeld: code, gedeelde bibliotheken, bestandskoppelingen, geheugen dat is aangevraagd maar nooit aangeraakt, en grote reserveringen die runtimes uit principe doen. Java, Go, Chrome, PostgreSQL en alles wat een grote mmap-arena gebruikt reserveren routinematig honderden gigabytes aan adressen die ze nooit zullen gebruiken. Een adres reserveren kost niets; alleen een pagina aanraken kost geheugen, en aangeraakte pagina's verschijnen in RES.

Er is een geval waarin VIRT een blik waard is: als hij gestaag en eindeloos oploopt terwijl RES vlak blijft, lekt er iets koppelingen in plaats van geheugen. Negeer de kolom verder, of druk op f en haal hem weg zodat hij je oog niet meer trekt.

7.4 Waar de getallen werkelijk vandaan komen

top berekent bijna niets over je machine. Hij opent bestanden, leest ze, trekt de ene meting van de vorige af, en tekent het resultaat. Elk getal in dit artikel staat in een bestand dat je zelf kunt lezen.

De vijf samenvattingsregels komen uit drie bestanden, een keer per verversing gelezen:

/proc/loadavg      the load average line
/proc/meminfo      both memory lines
/proc/stat         the %Cpu(s) line and the task state counts
/proc/uptime       the "up 6:11" part of the first line

Elke procesregel komt uit nog twee bestanden, een keer per proces per verversing gelezen:

/proc/PID/stat     PID, state, PR, NI, utime, stime, last used CPU  <- most columns
/proc/PID/statm    VIRT, RES, SHR
/proc/PID/cmdline  the COMMAND column, but only when `c' is on
/etc/passwd        turning the numeric UID into the USER column

Je hoeft dat niet op mijn woord aan te nemen. strace laat je elk bestand zien dat top voor een enkel beeld opent:

$ strace -f -e trace=openat -o tr.txt top -b -n 1 >/dev/null
$ grep -c openat tr.txt
2231

$ grep -oE '"/proc/[0-9]+/[a-z]+"' tr.txt | sed 's|/proc/[0-9]*/|/proc/PID/|' \
      | sort | uniq -c
   1042 "/proc/PID/statm"
   1042 "/proc/PID/stat"

Maak nu het rekensommetje, want het bevestigt bij toeval iets uit paragraaf 6.2. Er draaiden op dat moment 521 processen op de machine. 521 maal twee is 1042. top -b -n 1 las elk proces twee keer, en dat zijn de aanloopmeting en het beeld zelf, en daarom levert een batchrun met een enkel beeld toch een %CPU-kolom op. De 0,2 seconde uit paragraaf 6.2 is het gat tussen die twee rondes.

Zet commandoregels aan en er verschijnt een derde bestand per proces, precies even vaak geopend als de andere twee. De aantallen zijn 1044 in plaats van 1042 alleen omdat er tussen de twee runs een proces startte:

$ strace -f -e trace=openat -o tr2.txt top -b -n 1 -c >/dev/null
   1044 "/proc/PID/statm"
   1044 "/proc/PID/stat"
   1044 "/proc/PID/cmdline"     <- new, and only because of -c

Geen van die bestanden bestaat op een schijf. Ze zijn nul bytes groot, en de kernel maakt het antwoord op het moment dat je het leest:

$ ls -l /proc/meminfo /proc/stat /proc/1/stat
0 /proc/1/stat
0 /proc/meminfo
0 /proc/stat

Daar volgen drie nuttige dingen uit.

Je kunt top volledig overslaan. Voor een script is het bestand lezen beter dan een scherm ontleden: geen steekproef van 0,2 seconde, geen configuratiebestand, geen afkapping op 80 kolommen, geen failed tty get, en niets dat verandert als een collega op W drukt.

$ cut -d' ' -f1-3 /proc/loadavg            # the load average, three fields
1.63 1.39 1.29

$ awk '/^MemAvailable/ {print $2/1024 " MiB"}' /proc/meminfo
49164.1 MiB

$ awk '{print $1, $2}' /proc/1234/statm     # VIRT and RES, in pages

Alles wat dezelfde bestanden leest rapporteert dezelfde getallen. htop, btop, free, uptime, ps en de meeste monitoringagents zijn allemaal lezers van /proc. Daarom verandert het inruilen van top voor een mooier programma de presentatie en nooit de betekenis, en dat is paragraaf 7.8.

Wiens /proc je leest bepaalt wat je te horen krijgt. In een container horen de procesmappen bij de PID-namespace van de container, terwijl meminfo en stat rechtstreeks van de host komen. Die ene zin is de hele paragraaf 7.1.

7.5 top verandert wat het meet

top verschijnt in zijn eigen uitvoer, en niet onderaan:

 120269 pe7er     20   0   14868   5584   3536 R   8.3   0.0   0:00.02 top

Paragraaf 7.4 telde de kosten: 2231 bestandsopeningen voor een enkel beeld, twee per proces plus de samenvattingsbestanden. Dat is niet gratis, en het is meetbaar:

$ ls /proc | grep -c '^[0-9]'
516                                # processes to walk

$ time top -b -n 1 >/dev/null
real 0m0.23s   user 0m0.00s   sys 0m0.02s

Onschadelijk bij de standaard drie seconden. Niet onschadelijk bij -d 0.1 op een drukke productieserver met duizenden processen, waar top een van de zwaardere dingen kan worden die er draaien. De handleiding is ook eerlijk over de bijwerkingen en merkt bij het veld P (laatst gebruikte CPU) op: "the very act of running top may break this weak affinity and cause more processes to change CPUs more often".

Twee gewoontes volgen daaruit. Laat het interval met rust tenzij je een reden hebt, en als je top een week laat draaien in een vergeten SSH-sessie, besef dan dat hij 1.200 keer per uur is wakker geworden, elk uur, om elk proces op de machine langs te lopen.

7.6 De kernelthreads verbergen

Op deze machine meldt top ruim vijfhonderd taken, en de meeste zijn geen processen in enige zin die er voor jou toe doet. Een omgevingsvariabele haalt elke kernelthread weg uit zowel de lijst als de tellingen:

$ top -b -n 1 | sed -n 2p
Tasks: 518 total,   1 running, 516 sleeping,   0 stopped,   1 zombie

$ LIBPROC_HIDE_KERNEL=1 top -b -n 1 | sed -n 2p
Tasks: 262 total,   1 running, 260 sleeping,   0 stopped,   1 zombie

518 wordt 262. De helft van alles wat top je liet zien was kworker, ksoftirqd, rcu_gp en consorten. De waarde die je instelt maakt niet uit, alleen dat de variabele bestaat, en het werkt voor de hele procps-familie, dus ps gehoorzaamt hem ook.

Zet hem in je shellprofiel op een server die je vaak beheert. Het maakt top merkbaar leesbaarder, en de kernelthreads die je echt moet zien, een kworker op 100 procent of een vastgelopen jbd2, zijn precies degene die je bewust gaat opzoeken.

7.7 Weten waar top ophoudt

top beantwoordt een vraag goed: wat gebeurt er nu op deze machine. Bijna elke frustratie ermee komt voort uit het stellen van een andere vraag.

atop verdient de bovenste regel. Als service geïnstalleerd bemonstert hij op een timer en schrijft hij elke meting naar een log, zodat je terug kunt kijken naar de tien minuten voordat de machine omviel. Dat is het ene ding dat top principieel niet kan, en het is precies wat je het liefst wilt als iemand een probleem meldt dat al voorbij is. Hij moet wel voor het incident geïnstalleerd zijn, en daar zit de hele moeilijkheid.

En voordat je een tool toevoegt: kijk of top al een smaller familielid heeft dat je vraag in een regel beantwoordt. uptime voor de load average, free -h voor de geheugensamenvatting, pgrep en pidof om een PID te vinden, w voor wie er ingelogd is. Ze komen allemaal uit hetzelfde procps-pakket en lezen dezelfde bestanden.

7.8 htop en btop, en waarom top nog steeds de moeite waard is

Vraag iemand naar top en binnen een zin krijg je te horen dat je beter htop kunt gebruiken. Dat advies klopt grotendeels. Het is ook, op een server die je net hebt gekregen, vaak nutteloos, en de reden is een regel pakketinformatie:

$ dpkg-query -W -f='${Package} ${Priority}\n' procps htop btop
btop optional
htop optional
procps required

procps, waar top in zit, is een required-pakket. Het zit in elke Debian- en Ubuntu-installatie, ook in de minimale. htop en btop zijn optional: iemand moet ze installeren, en atop stond op deze machine helemaal niet.

Dat onderscheid doet er juist toe op de momenten dat het er het meest toe doet. Een net opgeleverde VPS, een rescue-shell, een minimale containerimage, de server van een klant die je voor het eerst bekijkt, een machine waarvan het uitgaande netwerk precies datgene is dat stuk is. In al die gevallen is top wat je hebt, en is apt install htop geen optie. Leer top omdat hij er altijd is; gebruik htop als iemand zo vriendelijk is geweest hem te installeren.

Als hij er wel is, dan doet hij dit werkelijk beter:

Die laatste regel is een echte verbetering, en je ziet hem door beide op hetzelfde moment te draaien:

top      Tasks: 521 total,   2 running, 519 sleeping,   0 stopped,   0 zombie
htop     Tasks: 265, 2390 thr, 261 kthr; 3 running

Een getal tegenover drie. top zegt 521 taken; htop zegt 265 echte processen, 2390 threads daarbinnen, en 261 kernelthreads apart geteld. De tweede regel is simpelweg informatiever.

btop is weer iets anders: grafieken over tijd, muisondersteuning, en een uiterlijk dat een moderne terminal nodig heeft om goed te tonen. Het is prettig, en het is een kijkvenster in plaats van een tool waar je iets op bouwt.

Twee dingen aan htop verrassen mensen die van top komen, en het is goed om ze te weten voordat je ze op een draaiende machine typt:

$ top  -d 5        # 5 SECONDS between refreshes
$ htop -d 5        # 0.5 seconds. htop counts in TENTHS of a second.

De handleiding is er duidelijk over dat htop die waarde afkapt tussen 1 en 100 tienden, dus zijn traagste verversing is tien seconden en zijn snelste een tiende. En het tweede verschil doet ertoe als je hem hoopte te scripten:

$ top -n 1 | head -3
top: failed tty get                # refuses cleanly, exit code 1

$ htop -n 1 | head -3
[?1049h[22;0;0t[1;24r(B[m[4l[?7h[H[2J ...
                                   # raw escape codes into your pipe, exit code 0

htop heeft geen batchmodus. Hij heeft wel -n om het aantal beelden te beperken, maar die beelden zijn nog steeds schermvullende tekeninstructies, dus een script dat ze opvangt krijgt een scherm vol terminalstuurcodes en geen foutmelding die dat vertelt. Voor alles wat onbeheerd draait blijven top -b en ps over, en dat is de conclusie van paragraaf 9.1 die uit een andere richting komt aanlopen.

Nu het deel dat belangrijker is dan al het bovenstaande. htop en btop lezen dezelfde /proc-bestanden die top leest. Het zijn mooiere vensters op identieke getallen, dus elke misvatting in dit artikel overleeft de overstap ongeschonden. De containerval uit paragraaf 7.1 is het duidelijkste bewijs, met htop geïnstalleerd in dezelfde container van 256 MiB:

$ docker run --rm -t -m 256m --cpus 1 ubuntu:24.04 \
      sh -c 'apt-get install -y htop >/dev/null; cat /sys/fs/cgroup/memory.max; htop'
268435456                          # the container's real limit: 256 MiB

15.1G/62.5G                        # what htop's memory meter shows
Load average: 1.40 1.27 1.29       # and the host's load average

62,5 GiB, het RAM van de host, in een container die 256 MiB mag gebruiken. Precies wat top deed, want het is precies hetzelfde bestand dat gelezen wordt. Een mooiere meter zorgt er niet voor dat het getal iets anders betekent.

De eerlijke samenvatting is dus deze. htop is het betere programma om voor te zitten, en het is de moeite waard om op elke machine die van jou is te installeren. Het is geen vervanging voor het weten wat de load average telt, wat RES dubbel telt, of van wie het geheugen is waar je naar kijkt, en dat zijn de dingen die mensen werkelijk een middag kosten.

9. Veelgemaakte fouten

9.1 top versus ps, en de %CPU die het er niet mee eens is

Beide programma's drukken een kolom af die %CPU heet. Ze betekenen totaal verschillende dingen, en het verschil is niet klein. Dit proces verbrandde zeven seconden CPU en ging daarna slapen:

$ top -b -n 1 -p 120358 | tail -1
 120358 pe7er     20   0    8656   2068   2068 S   0.0   0.0   0:07.04 sleep

$ ps -o pid,%cpu,time,etime,comm -p 120358
    PID %CPU     TIME     ELAPSED COMMAND
 120358 67.4 00:00:07       00:10 sleep

# and it is not the first-frame problem from section 6.2 either,
# the second frame agrees:
$ top -b -n 2 -d 1 -p 120358 | tail -1
 120358 pe7er     20   0    8656   2068   2068 S   0.0   0.0   0:07.04 sleep

Nul, en 67,4, voor hetzelfde proces op hetzelfde moment. Geen van beide is fout:

• top meldt CPU die sinds de vorige verversing is gebruikt. Het proces slaapt nu, dus 0,0 klopt.
• ps meldt de totale CPU gedeeld door de totale levensduur. Zeven seconden CPU in tien seconden leven is 67,4 procent, gemiddeld over het hele bestaan.

Daarom kan ps aux een webserverproces op 40 procent tonen dat helemaal niets doet: het was een uur geleden druk bij het opstarten en het gemiddelde herstelt nooit meer. Als je het cijfer van ps binnen top wilt, is het veld %CUU precies dat, en met beide kolommen naast elkaar beantwoord je in een oogopslag de vraag "is dit proces nu druk, of is het altijd druk geweest?".

De heldere scheiding: top is om te kijken, ps is om te scripten. Als een script een processenlijst nodig heeft, is ps -eo pid,pcpu,rss,comm --sort=-pcpu korter, sneller, stabieler en vrij van elke valkuil uit sectie 6.

9.2 Mythe versus werkelijkheid

9.3 Andere valkuilen om te vermijden

• Op k en dan op Enter drukken. De PID staat standaard op de eerste regel, en dat is het drukste proces op de machine. Dat is zelden het proces dat je bedoelde.
• -d 0.1 laten draaien op een productieserver. Elke verversing leest meerdere bestanden voor elk proces. Op 0,1 seconde wordt top op een machine met duizenden processen onderdeel van de belasting die hij rapporteert.
• De uitvoer van top op kolomnummer ontleden. De kolommen hangen af van het rcfile, de schakelaars H en c en de breedte van de terminal. Gebruik in plaats daarvan ps -o met benoemde velden.
• %MEM vertrouwen binnen een container. De noemer is het RAM van de host, dus een proces op zijn containerlimiet kan 0,4 procent aangeven.
• Achter een kworker-thread aangaan. Een drukke kworker is de kernel die werk doet voor iets. Zoek het proces dat het veroorzaakt in plaats van een kernelthread te willen renicen.
• %CPU lezen meteen nadat je top hebt gestart. Het eerste scherm is het onbetrouwbare. Wacht op de tweede verversing voordat je iets gelooft.
• Aannemen dat Tasks: 517 total 517 programma's betekent. De helft zijn kernelthreads (paragraaf 7.6), en met H aan schakelt de telling naar threads en springt hij weer omhoog.
• Een zombie afbreken. Een Z-proces is al dood en houdt geen geheugen vast. Het wacht tot zijn ouder de afsluitstatus ophaalt, dus het proces om naar te kijken is de ouder.
• Sorteren op %CPU terwijl je met L zoekt. De handleiding waarschuwt hier rechtstreeks voor: regels verschuiven tussen verversingen, dus een zoekopdracht op een onstabiele sorteerkolom raakt steeds zijn plek kwijt. Sorteer op PID terwijl je zoekt.
• Hem vanuit een script aanroepen zonder -b. top neemt de terminal over, dus een cron-taak of een CI-stap die de batchmodus vergeet levert failed tty get en foutcode 1 op, en verder niets.
• Swap die gebruikt wordt als probleem melden. Pagina's die inactief naar buiten zijn verplaatst zijn de kernel die zijn werk doet. Swap die actief heen en weer gaat is het probleem, en vmstat 1 laat dat zien in de kolommen si en so.