Linux performancecommando's: knelpunten vinden

Wanneer een gameserver hapert, een webapp traag wordt of een VPS plotseling niet meer reageert, is je eerste taak om het "waarom" met cijfers te beantwoorden. De juiste Linux performancecommando's bestaan precies hiervoor: in plaats van gokken laten ze je binnen seconden zien of het knelpunt in de CPU, het geheugen, de schijf of het netwerk zit. In dit artikel loop ik door het viertal top, htop, iostat en vmstat aan de hand van echte scenario's, en leg ik uit hoe je de cijfers leest die ze produceren.

Begin met de load average: top

top komt met vrijwel elke distributie mee, dus dat is de eerste plek om te kijken. De load average-regel bovenaan toont het aantal uitvoerbare taken over de laatste 1, 5 en 15 minuten. De praktische regel: deel die waarde door je aantal cores. Vind het aantal met nproc; op een machine met 4 cores betekent een load van 4 ongeveer 100% benutting.

nproc            # aantal cores
uptime           # alleen de load-average-regel
top              # interactieve monitoring

Binnen top versmalt het lezen van de velden op de CPU-regel het knelpunt: us is CPU besteed aan gebruikersapplicaties, sy is kernel- (systeem-)CPU, en wa is schijf-/IO-wachttijd. Een hoge wa betekent "de CPU is inactief maar wacht op de schijf" en stuurt je direct naar de opslagkant. De P-toets sorteert processen op CPU en M op geheugen, zodat je meteen ziet welk proces het meeste van een bepaalde resource opslokt.

Een beter leesbaar beeld: htop

htop is de kleurrijke, muisvriendelijke moderne versie van top. Hij is zelden standaard geïnstalleerd; voeg hem toe met apt install htop of dnf install htop. De balken bovenaan tonen elke core apart, wat gevallen blootlegt waarin een enkele core verzadigd is (typisch voor single-threaded processen).

• F6 wijzigt de sorteerkolom zodat je het duurste proces naar voren haalt.
• F4 filtert om alleen het proces te tonen dat je interesseert (bijvoorbeeld mysqld of de binary van je gameserver).
• F5 de boomweergave verheldert welk ouderproces welke kindprocessen heeft voortgebracht.

In de geheugenbalk is groen gebruikt RAM en geel buffers/cache. Het is volkomen normaal dat Linux vrij RAM aan cache toewijst; voordat je in paniek raakt dat "het RAM vol is", bevestig het echte knelpunt door naar het swap-gebruik te kijken. Als swap blijft stijgen, is het geheugen werkelijk onvoldoende.

Voor schijfknelpunten: iostat

Als je een hoge wa zag, is iostat de volgende stap. De tool zit in het pakket sysstat (apt install sysstat). Je krijgt zinvolle data via bemonstering met intervallen, niet via één momentopname:

iostat -x 2      # uitgebreide stats elke 2 seconden

De cruciale kolommen zijn: %util, het percentage tijd dat de schijf bezig was; blijft dit consequent boven 90%, dan is de schijf verzadigd. await is de gemiddelde tijd die een I/O-verzoek nodig heeft om te voltooien (ms); verwacht enkele cijfers op een SSD en tientallen ms op een draaiende schijf, dus waarden ver daarboven zijn een waarschuwingssignaal. r/s en w/s geven het aantal lees-/schrijfbewerkingen per seconde. Negeer de eerste regel, want dat is het gemiddelde sinds het opstarten; kijk naar de tweede regel en verder.

Op een databaseserver betekenen hoge await en %util dat ofwel je queries de schijf onnodig belasten, ofwel het RAM te klein is waardoor het systeem steeds naar de schijf gaat. De oplossing is meestal niet een snellere schijf, maar het indexeren van je queries of het toevoegen van geheugen.

Voor het totaalbeeld: vmstat

vmstat vat CPU, geheugen, swap en I/O samen op één regel, wat hem ideaal maakt als "eerste diagnose"-tool. Draai hem ook met een interval:

vmstat 2         # samenvatting elke 2 seconden

De te lezen velden: de kolom r is het aantal processen dat klaar is om te draaien maar op de CPU wacht; blijft dit boven je aantal cores, dan heb je een CPU-knelpunt. b telt processen in ononderbreekbare slaap (meestal wachtend op I/O). si/so zijn het geheugen dat per seconde in/uit swap wordt verplaatst; niet-nul, aanhoudende waarden zijn een stevig bewijs van geheugendruk. wa is opnieuw I/O-wachttijd. Tot slot, als cs (context switches) en in (interrupts) erg hoog zijn, heb je mogelijk een werklast die buitensporig veel context switching veroorzaakt (bijvoorbeeld duizenden kortlevende processen).

Een praktische diagnosestroom

De meest efficiënte aanpak is om deze tools als een stroom te gebruiken in plaats van één voor één:

• Stap 1: bekijk met top of htop de load average en welk proces opvalt.
• Stap 2: bepaal of de CPU vol is of wa hoog. Bij CPU: profileer het proces; bij wa: ga naar de schijf.
• Stap 3: bevestig met iostat -x 2 of de schijf verzadigd is (%util, await).
• Stap 4: controleer met vmstat 2 het swap-gebruik (si/so) om te verhelderen of er geheugendruk is.
• Stap 5: bij verdenking van het netwerk, controleer het aantal verbindingen en het luisterende proces met ss -s en ss -tnp.

Deze vijf stappen veranderen een vage klacht als "de server is traag" binnen enkele minuten in een concrete bevinding zoals "MySQL verzadigt de schijf" of "een enkele core zit vast". Voor continue monitoring kun je overstappen op tools als Netdata of Prometheus die op deze commando's voortbouwen; maar eerst weten hoe je de handmatige commando's leest, maakt het interpreteren van de grafieken in dashboards ook veel makkelijker.

Veelgestelde vragen

Moet ik top of htop gebruiken?

Beide tonen dezelfde onderliggende data. top is betrouwbaar in noodgevallen omdat hij er altijd is; htop is beter leesbaar, navigeerbaar met de muis en maakt taken als het stoppen of filteren van processen makkelijker. Voor dagelijks gebruik raad ik aan htop te installeren maar ook top te kunnen lezen.

Welke load average moet me zorgen baren?

Er is geen enkele drempel; deel de waarde door je aantal cores. Op een systeem met 4 cores betekent rond 4 vol belast en 8 het dubbele. Maar om te onderscheiden of de belasting van de CPU of van I/O-wachttijd komt, controleer altijd ook de wa-waarde.

Waarom ziet de eerste regel van iostat er anders uit?

De eerste regel is het gemiddelde dat sinds het opstarten is opgebouwd en weerspiegelt niet de huidige toestand. Om het echte gedrag te zien, draai hem met een interval zoals iostat -x 2 en lees vanaf de tweede regel.

Worstelt jouw server met knelpunten? We kunnen de prestaties van je gameserver, VPS of database samen diagnosticeren en omzetten in een blijvende oplossing. Neem contact op en laten we je server versnellen.