Vragen over de belasting?

Geen blauwe envelop, wel meer grip op de performance van je Linux-systeem

Waarom tonen commando's als top, uptime en w hoge load averages, terwijl er nauwelijks CPU-belasting is? Kunnen zombie-processen de oorzaak zijn van slechte responstijden? Hoe kan ik bepalen waar een proces (thread) precies op wacht als het geen voortgang laat zien? Is de kernel een proces? Is er sprake van een context-switch als een proces (thread) een system call uitvoert? Hoe kan ik de bandbreedte van mijn hardware-resources zo goed mogelijk verdelen?

Als Linux-gebruiker, Linux-systeembeheerder, Kubernetes-administrator of ontwikkelaar komen regelmatig performance-gerelateerde vragen bij je op die alles te maken hebben met de belasting van je systeem. Het is dan fijn dat je kunt terugvallen op gedegen kennis over hoe de Linux-kernel CPU-, memory- en disk-capaciteit verdeelt over de processen die daar aanspraak op maken. Deze kennis maakt het mogelijk om een gedegen analyse te maken zodat je met gefundeerde oplossingen kunt komen.

System load averages

Zo is het belangrijk om te weten wat de drie load average getallen die door commando's als top, uptime en w worden getoond precies aanduiden. In de man-pagina's van deze drie commando's staat iets vaags als "system load averages for the past 1, 5, and 15 minutes". Maar wat betekent "system load averages" concreet?

Bij oudere UNIX-implementaties (zoals AIX, HP-UX of Solaris) geeft deze waarde aan hoeveel threads (de actieve executie-lijnen in processen) er gemiddeld aanspraak maken op een CPU gedurende een bepaalde tijdsperiode, hetzij threads die daadwerkelijk van een CPU gebruik maken maar ook de threads die op hun beurt wachten voor CPU-capaciteit in de zogenaamde 'runqueue' omdat alle CPU's op dat moment bezet zijn. Een vuistregel is dan: als het load average getal groter is dan het aantal CPU's, dan wordt je systeem in die periode qua CPU-capaciteit overvraagt.

Bij Linux geven de load average getallen niet alleen aan hoeveel threads op enig moment aanspraak maken op de CPU, maar ook hoeveel threads gemiddeld zijn geblokkeerd in een niet-interrumpeerbare wachttoestand. Threads die momenteel aanspraak maken op de CPU herken je aan de status R in de uitvoer van bijv. top (kolom S) en threads die niet-interrumpeerbaar geblokkeerd zijn hebben de status D in diezelfde uitvoer. Overigens zullen de meeste threads de status S hebben, wat duidt op een interrumpeerbare wachttoestand. Interrumpeerbaar betekent dat de wachttoestand voortijdig onderbroken wordt bij ontvangst van een signal. Zo'n signal komt binnen als de gebruiker op de ctrl-C toets drukt of een signal stuurt met het kill commando.

Een voorbeeld van de uitvoer van top:

top - 09:47:13 up 2 days, 20:39,  1 user,  load average: 1.96, 0.98, 0.70
Tasks: 571 total,   4 running, 567 sleeping,   0 stopped,   0 zombie
%Cpu(s):  8.7 us,  1.2 sy,  0.0 ni, 85.2 id,  4.5 wa,  0.2 hi,  0.2 si,  0.0 st
MiB Mem :  31802.1 total,    656.9 free,  14911.5 used,  18000.8 buff/cache
MiB Swap:   8192.0 total,   8100.0 free,     92.0 used.  16890.6 avail Mem

    PID USER    PR  NI    VIRT    RES ...  S  %CPU  %MEM     TIME+ COMMAND
1771627 gerlof  20   0    2412   1228      R  99.8   0.0   0:48.84 usecpu
1771823 gerlof  20   0  232924   7212      D  28.7   0.0   0:10.07 grep
   5555 gerlof  20   0 5186504 262244      S   4.8   0.8  39:49.55 gnome-shell
  91098 root    20   0 1974316 593460      S   2.4   1.8  86:11.77 k3s

Meestal wachten niet-interrumpeerbare threads tot de disk een uitstaand lees- of schrijf-verzoek klaarmeldt. Daardoor kan een hoge load average bij Linux (over)belasting van de CPU's aanduiden, maar net zo goed (over)belasting van de disk-resources! Ook tijdens een lees- of schrijf-verzoek via NFS, wacht de thread niet-interrumpeerbaar op het antwoord van de NFS server. Als het antwoord van de NFS server uitblijft (vanwege een software- of hardware-fout) is het daardoor niet mogelijk om het proces af te breken, zelfs niet met 'kill -9'.

Bij Linux-systemen kun je dus uit het load average getal zelf helaas geen eenduidige conclusies trekken. Hoe je toch adequaat kunt analyseren en troubleshooten op een Linux-systeem? Dat leer je tijdens onze Linux Performance Analysis and Tuning cursus!

Cursus Linux Performance Analysis and Tuning

Deze cursus is maximaal 4 dagen en modulair van opzet. De eerste dag is essentieel en legt de basis voor de drie daarop volgende cursusdagen. Die drie daaropvolgende dagen kunnen na die eerste dag los van elkaar gevolgd worden en behandelen telkens een specifieke hardware-resource, resp. CPU, memory en disk. In zo'n resource-specifieke dag behandelen we de hardware-aspecten, de verdeling van de resource-capaciteit over de processen en de analyse van zo'n resource (inclusief mogelijkheden tot verbetering).

• Op de eerste dag komen onderwerpen aan de orde die te maken hebben met het verzamelen van tellers, het gebruik van tooling in het algemeen, process management en multi-threading, en antwoorden op andere vragen waarmee ik deze blog begon.
• Op de tweede dag wordt de CPU besproken als mogelijke bottleneck. We gaan hier in op hardware-aspecten, maar ook op de wijze waarop de kernel de CPU-capaciteit verdeelt over de threads (CPU scheduling) en hoe je dat kunt beïnvloeden. Verwacht hier antwoorden op vragen als: wat is de werkelijke impact als ik de nice-waarde van een proces wijzig, heeft het zin om belangrijke processen realtime te starten, hoe kan ik batchprocessen uitvoeren die alleen de resterende processorcapaciteit verbruiken, hoe kan ik mijn proces aan bepaalde CPU's binden, etcetera.
• Op de derde dag gaan we in op memory als mogelijke bottleneck. Afgezien van de hardware-aspecten, behandelen we de wijze waarop de kernel de memory-capaciteit verdeelt (memory management). Verwacht hier antwoorden op vragen als: hoe kan ik processen met een memory leakage ontdekken en hoe kan ik voorkomen dat ze de algehele systeemprestaties schaden, wat is het verschil tussen virtueel en fysiek geheugengebruik van een proces, wat is de huidige grootte van de dynamisch schaalbare pagecache en kan ik agressief gedrag van deze pagecache voorkomen, welk proces wordt precies beëindigd wanneer mijn systeem geen vrij geheugen en swapruimte meer over heeft (out-of-memory killing), hoe kan ik mijn kritieke processen beschermen tegen out-of-memory killing, waarom swapt de kernel proces-delen uit terwijl er voldoende geheugen vrij is, wat zijn NUMA memory policies, etcetera.
• Op de vierde dag wordt de disk besproken als mogelijke bottleneck. We gaan kort in op de hardware-aspecten van HDD's en SSD's, maar ook uitgebreider op de wijze waarop de kernel de disk-bandbreedte verdeelt over de threads (I/O scheduling) en wat de invloed is van diverse caches in de kernel. Verwacht hier antwoorden op vragen als: is een disk met een busy percentage van 100% werkelijk verzadigd, hoe werkt caching van populaire disk data en hoe kan ik voorkomen dat bepaalde data door de kernel wordt gecachet, wat is een inode en dentry cache, hoe stel ik een specifieke I/O scheduler in voor een disk, wat is de invloed van bepaalde RAID-technieken op de disk throughput, welke mount-opties hebben invloed op de disk-belasting, hoe kan ik voorkomen dat batchprocessen te veel diskbandbreedte verbruiken ten koste van interactieve processen, etcetera.

Na de eerste dag kun je kiezen welke extra dag(en) je wilt volgen over een specifieke resource: CPU, memory en/of disk. Je boekt (en betaalt) dus voor twee, drie of vier dagen cursus. Vragen over de belasting maken we op deze manier leuker én makkelijker!