Linux server traag: diagnose van hoog CPU-gebruik, geheugentekort en schijf-I/O

Stap 1: de eerste check in 60 seconden

Voordat je gaat gokken, wil je eerst weten wat er traag is. Een server voelt traag aan, maar dat zegt nog niets over de oorzaak. Begin daarom altijd met dezelfde korte routine. Ervaren beheerders doen dit bijna op de automatische piloot.

1. uptime: toont de load average over 1, 5 en 15 minuten.
2. top of htop: laat live zien welke processen CPU en geheugen gebruiken.
3. free -h: geeft de stand van RAM en swap.
4. vmstat 1 5: toont vijf seconden lang CPU, geheugen, swap en I/O naast elkaar.
5. df -h: controleert of een bestandssysteem vol zit.

De load average is hierbij je eerste graadmeter. Deze waarde moet je altijd vergelijken met het aantal CPU-cores, dat je opvraagt met nproc. Een load van 4,0 is op een server met 8 cores rustig, maar op een server met 2 cores zit je flink in de knel.

$ uptime
 14:32:07 up 41 days,  3:12,  2 users,  load average: 7.82, 6.45, 4.10

$ nproc
4

In dit voorbeeld is de load bijna twee keer zo hoog als het aantal cores, en stijgend. Dat is een duidelijk signaal dat processen in de rij staan om uitgevoerd te worden.

Hoog CPU-gebruik op Linux: zo vind je de veroorzaker

Hoog CPU-gebruik op Linux is de meest voorkomende reden voor een trage server. Open top en let op de bovenste regel met CPU-statistieken. Die vertelt veel meer dan het totaalpercentage alleen.

De CPU-kolommen in top uitgelegd

• us (user): tijd die applicaties verbruiken. Hoog? Dan draait er een zwaar proces, zoals een PHP-worker, database of script.
• sy (system): tijd in de kernel. Structureel hoog kan wijzen op veel context switches of een netwerk- of driverprobleem.
• wa (iowait): tijd waarin de CPU wacht op I/O. Hierover meer in het volgende hoofdstuk.
• st (steal): tijd die een virtuele machine kwijtraakt aan andere VM's op dezelfde host. Hoog? Dan is je hypervisor overbelast, en kun je zelf weinig doen.
• id (idle): ongebruikte capaciteit.

Processen sorteren op CPU

In top staat de lijst standaard op CPU gesorteerd. Wil je een momentopname die je kunt kopiëren naar een ticket of chat? Gebruik dan:

ps aux --sort=-%cpu | head -n 10

Kijk niet alleen naar het proces met de hoogste waarde, maar ook naar het aantal instanties. Honderd Apache- of PHP-FPM-processen die elk 3 procent gebruiken, vormen samen een groter probleem dan één proces op 80 procent. Met htop activeer je met F5 de boomweergave, zodat je ziet welk parent-proces al die kinderen heeft gestart.

Typische oorzaken van CPU-pieken

• Een vastgelopen of eindeloos draaiende cronjob
• Een webapplicatie die onder piekbelasting te weinig workers of te zware queries heeft
• Een backup- of compressieproces overdag in plaats van 's nachts
• Ongewenste software, zoals een cryptominer na een inbraak

Linux geheugen vol: zo spoor je het op

Als je Linux-geheugen vol lijkt te zijn, is dat vaak minder dramatisch dan het klinkt. Linux gebruikt ongebruikt RAM bewust als bestandscache om dingen sneller te maken. Dat geheugen komt direct vrij zodra een applicatie het nodig heeft.

De juiste kolom lezen in free -h

$ free -h
               total   used   free  shared  buff/cache  available
Mem:            15Gi   6.1Gi  400Mi  210Mi       9.0Gi      8.4Gi
Swap:          2.0Gi   1.3Gi  700Mi

Kijk niet naar free, maar naar available. Dat is het geheugen dat daadwerkelijk beschikbaar is voor nieuwe processen, inclusief herbruikbare cache. In het voorbeeld hierboven is dat 8,4 GiB, dus er is geen geheugentekort. Wel is er 1,3 GiB swap in gebruik, iets om in de gaten te houden.

Hoe vind je welk proces het meeste geheugen gebruikt?

Gebruik ps aux --sort=-%mem | head -n 10 voor de tien grootste geheugengebruikers. In top sorteer je met Shift+M. Let op de kolom RES (resident memory): dat is het fysieke RAM dat een proces nu echt gebruikt. De kolom VIRT is vaak misleidend groot en zegt weinig.

Wanneer swappen een probleem wordt

Een beetje swap in gebruik is normaal. Problematisch wordt het als het systeem actief heen en weer schuift. Dat zie je in vmstat 1 aan de kolommen si (swap in) en so (swap out). Staan daar continu waarden boven nul, dan is er echt te weinig RAM en wordt alles trager, omdat een schijf vele malen langzamer is dan geheugen.

De OOM-killer

Raakt het geheugen volledig op, dan grijpt de kernel in en beëindigt de OOM-killer een proces. Vaak is dat je database of webserver. Controleer of dit is gebeurd met:

dmesg -T | grep -i "out of memory"
journalctl -k | grep -i "killed process"

Zie je hier regelmatig meldingen, dan is er sprake van een structureel tekort of een geheugenlek (memory leak) in een applicatie. Een leak herken je aan een proces waarvan de RES-waarde dag na dag oploopt zonder ooit te dalen.

Iowait op Linux: wanneer de schijf het probleem is

Iowait is het percentage tijd dat de CPU idle is omdat hij moet wachten op een I/O-operatie, meestal van een schijf. Je ziet het als wa in top en vmstat. De CPU zelf is dan niet druk, maar processen komen niet vooruit omdat ze op data wachten.

Wat is een hoge iowait?

Als vuistregel geldt: korte pieken zijn normaal, maar een iowait die langdurig boven de 10 tot 20 procent ligt is een waarschuwing. Het typische beeld bij een schijfprobleem is een hoge load average, terwijl het CPU-gebruik laag is. Wie alleen naar CPU kijkt, snapt dan niet waarom alles stroperig voelt.

Zo meet je schijf-I/O met iostat

Installeer het pakket sysstat en draai:

iostat -x 2 5

De belangrijkste kolommen:

• %util: hoe bezet het apparaat is. Dicht bij 100 procent betekent verzadiging (bij SSD's en NVMe is dit getal minder strikt, omdat die parallel werken).
• await: gemiddelde wachttijd per I/O-verzoek in milliseconden. Op een SSD verwacht je enkele milliseconden; tientallen of honderden duiden op problemen.
• r/s en w/s: aantal lees- en schrijfoperaties per seconde.

Welk proces veroorzaakt de I/O?

Met iotop -oPa (vereist root) zie je per proces hoeveel er gelezen en geschreven wordt. Zo kom je erachter of het gaat om een backup, een databasedump, logrotatie of een applicatie die ongeremd logt. Een volle schijf kan overigens ook de oorzaak zijn: controleer altijd df -h én df -i, want ook uitgeputte inodes laten een server vastlopen.

Wanneer is de schijf zelf defect?

Een hoge iowait zonder duidelijke software-oorzaak kan wijzen op een falende schijf. Controleer de SMART-status met smartctl -a /dev/sda en zoek in dmesg naar I/O-errors. Zie je herstelpogingen, reallocated sectors of een gedegradeerde RAID-array (cat /proc/mdstat), neem dan snel actie en zorg eerst voor een goede back-up.

Hardware, softwarefout of aanval?

Als je weet welke resource knelt, is de volgende vraag waarom. Grofweg zijn er drie categorieën.

1. Te weinig capaciteit (hardware of VM-formaat)

De belasting is gelijkmatig gegroeid en past niet meer bij de server. Je ziet geleidelijke verslechtering over weken of maanden, en piekmomenten die samenvallen met drukte in je bedrijf. De oplossing is opschalen, of de workload optimaliseren (bijvoorbeeld database-indexen, caching, tuning van PHP-FPM of MySQL).

2. Een softwarefout of misconfiguratie

De vertraging begon plotseling na een update, deployment of configuratiewijziging. Kenmerkend zijn één specifiek proces dat uit de pas loopt, een geheugenlek, of logbestanden die onbeperkt groeien. Rollback of een fix lost dit meestal snel op.

3. Een aanval of misbruik

Hier moet je alert zijn. Waarschuwingssignalen zijn:

• Onbekende processen met een hoog CPU-gebruik, vaak met een willekeurige of nagebootste naam (cryptominers)
• Veel mislukte SSH-logins in /var/log/auth.log of via journalctl -u ssh
• Ongewoon veel uitgaand netwerkverkeer, te zien met iftop of nethogs
• Onbekende cronjobs of gebruikers (crontab -l voor alle gebruikers, /etc/passwd)
• Een plotselinge piek aan webverzoeken uit dezelfde IP-reeksen, wat op een (D)DoS of scraper kan wijzen

Vermoed je een inbraak? Probeer het probleem dan niet "even" op te lossen door het proces te killen. Bewijsmateriaal gaat verloren en de aanvaller heeft vaak al persistentie ingebouwd. Isoleer de server, maak een kopie van logs en laat het onderzoeken.

Overzicht: symptoom, oorzaak en commando

Gebruik deze tabel als snelle spiekbrief tijdens een incident.

Linux performance problemen systematisch aanpakken

Bij Linux performance problemen werkt een vaste volgorde het best: meten, hypothese opstellen, één ding wijzigen, opnieuw meten. De grootste fout die we in de praktijk zien is dat er tegelijk meerdere dingen worden aangepast, waardoor niemand meer weet wat het probleem heeft opgelost, of juist heeft verergerd.

1. Leg de huidige situatie vast. Sla de uitvoer van top, vmstat en iostat op, voordat je iets verandert.
2. Bepaal het tijdstip. Wanneer begon het? Kijk naar recente deployments, updates en cronjobs.
3. Identificeer de bottleneck. CPU, geheugen, schijf of netwerk. Meestal is het er één.
4. Vind het verantwoordelijke proces of de gebruiker.
5. Pas één wijziging toe en meet het effect.
6. Documenteer wat je hebt gevonden, zodat je het de volgende keer sneller oplost.

Performance problemen voorkomen

De beste diagnose is die je niet hoeft uit te voeren omdat je het probleem eerder zag aankomen. Voor een MKB-omgeving zijn dit de maatregelen met de beste verhouding tussen moeite en opbrengst:

• Monitoring met historie. Tools als Prometheus met Grafana, Zabbix of Netdata laten trends zien. Een geheugenlek dat dagelijks 2 procent groeit, vang je zo weken voordat het crasht.
• Alerts op de juiste drempels. Bijvoorbeeld op beschikbaar geheugen, swapactiviteit, schijfgebruik boven 85 procent en load average ten opzichte van het aantal cores.
• Logrotatie en opschoonbeleid. Zorg dat logs, tijdelijke bestanden en oude back-ups niet ongemerkt de schijf vullen.
• Resourcelimieten. Stel met systemd (MemoryMax, CPUQuota) grenzen in, zodat één proces niet de hele server meeneemt.
• Back-ups buiten kantoortijden. En test regelmatig of ze ook werken.
• Regelmatig updaten en hardenen. Dit verkleint de kans op misbruik door aanvallers die jouw server gratis willen laten minen of spammen.

Wanneer schakel je een Linux-expert in?

Veel problemen los je met bovenstaande commando's zelf op. Toch zijn er situaties waarin het verstandiger is om hulp te halen:

• De server ligt plat of is productiekritisch en elke minuut downtime kost geld.
• Je vermoedt een inbraak of misbruik en wilt geen bewijs vernietigen.
• De oorzaak zit diep, bijvoorbeeld in kernelparameters, een database-engine of een RAID-controller.
• Je hebt wel de bottleneck gevonden, maar weet niet hoe je die structureel oplost zonder risico.
• Het probleem komt steeds terug en niemand in je team heeft tijd voor een grondige analyse.

Dat is precies waar wij bij LinuxHulp.nl voor staan. Onze beheerders hebben samen ruim 30 jaar ervaring met Linux-omgevingen. Bekijk onze diensten voor Linux-beheer en spoedhulp, of lees op de prijzenpagina wat hulp kost.