Kennisbank / Linux performance diagnose

Linux performance: CPU, geheugen en I/O systematisch onderzoeken

Auteur: DEWOLF.IT

Een bruikbare Linux performance diagnose begint bij de vertraagde gebruikershandeling en het tijdvenster waarin die optreedt. CPU, geheugen en storage zijn mogelijke oorzaken; losse meetwaarden vertellen zelden welke component de werkelijke beperking vormt.

Scope: RHEL 8/9 en vergelijkbare Linux-systemen met procps-ng en sysstat; kolommen verschillen per versie.

Toepassing. Linux/RHEL 8/9 met procps-ng en sysstat. Installeer ontbrekende meettools volgens het beheerproces; historische sar-data bestaat alleen als collection eerder was ingericht.

Probleem en achtergrond: bepaal eerst wat ‘traag’ betekent

Een hoog load average is geen diagnose. Vraag welke transactie vertraagt, sinds wanneer, voor hoeveel gebruikers en ten opzichte van welke normale waarde. Een batch die langer duurt kan een CPU-beperking hebben, maar ook wachten op een externe database. Definieer het tijdvenster, de normale belasting en een functionele maat, bijvoorbeeld transactielatentie.

Leg hypotheses één voor één naast meetgegevens. Verzamel tegelijkertijd host-, proces- en applicatiemetrics; gemiddelden van verschillende tijdvensters kun je slecht vergelijken. Noteer timezone, meetinterval en recente wijzigingen. De volgende opdrachten verzamelen beperkte samples en veranderen geen tuninginstellingen.

1. Maak een eerste momentopname

date -Is
uptime
nproc
free -h
vmstat 1 10
iostat -xz 1 10
sar -u 1 10
ps -eo pid,comm,stat,%cpu,%mem --sort=-%cpu | head -n 20

De eerste vmstat- en iostat-rapporten bevatten deels gemiddelden sinds boot; vervolgmetingen laten het gekozen interval zien. Beoordeel dus vooral de latere samples bij een actuele storing. Kolomnamen verschillen per toolversie: raadpleeg bij twijfel de lokale manpage en sla de versie op met de meting.

2. CPU: zoek wachtrij en verbruik

Load average telt runnable taken en taken in uninterruptible sleep mee. Daardoor kan load stijgen door CPU-concurrentie of bijvoorbeeld I/O-wachten. Vergelijk met beschikbare CPU-capaciteit, maar controleer ook quota en cpusets van de betrokken workload. Een container kan zijn limiet raken terwijl de host nog vrije CPU heeft. Zie proc_loadavg.

vmstat r geeft runnable processen; us en sy tonen user- en kerneltijd. st kan in een VM wijzen op CPU-tijd die de hypervisor aan de guest onthoudt. Hoge r met weinig idle ondersteunt een CPU-capaciteitshypothese. Lage hostbelasting met één drukke core kan juist wijzen op een niet-parallel onderdeel. Bekijk per-CPU-metingen voordat je meer cores als oplossing kiest.

sar -P ALL 1 10
pidstat -u 1 10
vmstat 1 10

pidstat hoort bij sysstat. Koppel PID’s aan de werkelijke workload en kijk of het verbruik meebeweegt met de vertraagde transactie. Een hoog CPU-percentage kan normaal zijn voor een batch; het wordt een probleem als de benodigde doorvoer of latency niet wordt gehaald.

3. Geheugen: druk is relevanter dan ‘free’

Linux gebruikt geheugen voor cache. Kijk daarom naar available, swapactiviteit en fouten in plaats van alleen free. free rapporteert available als een inschatting van geheugen dat zonder swapping beschikbaar is voor nieuwe applicaties. Zie free.

free -h
vmstat 1 10
sar -r 1 10
sar -W 1 10
sudo journalctl -k --since '30 minutes ago' --no-pager

Aanhoudende si/so in vmstat kan op actieve swapping wijzen. Swapgebruik zonder actuele swapactiviteit is op zichzelf geen bewijs van een huidig probleem. Controleer de kernelmeldingen op OOM-events en onderzoek de cgrouplimieten van de workload. Een proces kan door een eigen memorylimiet worden geraakt terwijl de host nog voldoende geheugen heeft.

Maak onderscheid tussen groei in de applicatie, groei in caches en grenzen van het deployment. Vergelijk met een baseline van dezelfde workload. Verlaag niet blind swappiness en drop geen caches als eerste ingreep: dat verandert de situatie en kan de bestaande bottleneck verplaatsen.

4. I/O: verbind latency met het juiste device

iostat -x geeft uitgebreide devicecijfers. await is een gemiddelde I/O-afhandelingstijd inclusief wachttijd; bekijk ook queues en throughput. %util is geen universele verzadigingsgrens voor ieder modern parallel device. Bekijk de storagearchitectuur en applicatielatency voordat je ‘100% disk’ als conclusie gebruikt. Zie iostat.

lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS
iostat -xz 1 10
pidstat -d 1 10
findmnt -t nfs,nfs4

Koppel de applicatiebestanden aan het juiste filesystem en vervolgens aan de storageketen. Een lokaal devicecijfer beschrijft niet de latency van een externe NFS-server. Bij LVM, multipath of virtuele disks kunnen verschillende lagen dezelfde I/O weerspiegelen; tel zulke cijfers niet zonder inzicht bij elkaar op.

CPU iowait is geen directe meting van de tijd die jouw applicatie wacht. Het is een CPU-accountingcategorie en kan in een multicore omgeving misleidend zijn. Gebruik daarom de samenhang tussen geblokkeerde taken, device-latency en de eigen transacties.

5. Gebruik historie om pieken te verklaren

# Alleen als deze bestanden eerder door sysstat zijn verzameld.
sar -u -f /var/log/sa/saDD
sar -r -f /var/log/sa/saDD
sar -d -f /var/log/sa/saDD

Vervang saDD door het aanwezige bestand van de relevante dag en controleer tijdzone en interval. sar reconstrueert geen verleden zonder eerder verzamelde data. Vergelijk een probleemvenster met een gezonde periode met vergelijkbare belasting. De sar-handleiding beschrijft de rapportkeuzes.

Enterprise-aandachtspunten en valkuilen

Voer geen stressbenchmark op productie uit als vervanging voor diagnose. Bewaar meetresultaten met de applicatieversie en releasewijzigingen. Kies daarna één gerichte verandering met een voorspelde uitkomst, bijvoorbeeld minder queueing of lagere transactielatency. Meet onder vergelijkbare belasting en draai terug als de voorspelling niet uitkomt.

Stop de analyse niet bij één opvallend getal. Een lage gemiddelde CPU sluit korte pieken niet uit, een snel device sluit locks in de applicatie niet uit en meer RAM lost geen externe timeout op. Een bruikbaar incidentrapport beschrijft de gebruikersimpact, het bewijs voor de oorzaak en de meetbare uitkomst van de correctie.

Bronnen en versiecontrole

Technische referenties geraadpleegd op 30 september 2026. Controleer bij uitvoering de documentatie en manpages van de geïnstalleerde versie.

Load average
vmstat
free
iostat
sar

Gerelateerde artikelen

systemd troubleshooting: services, dependencies en restart-beleid
Podman in beheer: rootless containers, Quadlet en Docker-migratie
Enterprise Linux-beheer: tmp, journald, NFS en versionlock

Ondersteuning bij jouw platform

Wil je deze aanpak vertalen naar jouw omgeving? Bekijk Linux Consultancy of neem contact op met DEWOLF.IT.