{"id":21483,"date":"2026-09-17T11:51:02","date_gmt":"2026-09-17T09:51:02","guid":{"rendered":"https:\/\/webhosting.de\/linux-vmstat-richtig-interpretieren-performanceanalyse-monitoring\/"},"modified":"2026-09-17T11:51:02","modified_gmt":"2026-09-17T09:51:02","slug":"linux-vmstat-correct-interpreteren-prestatieanalyse-monitoring","status":"publish","type":"post","link":"https:\/\/webhosting.de\/nl\/linux-vmstat-richtig-interpretieren-performanceanalyse-monitoring\/","title":{"rendered":"vmstat onder Linux correct interpreteren voor een effectieve prestatieanalyse"},"content":{"rendered":"<p>Ik laat je zien hoe je vmstat onder Linux doelgericht kunt interpreteren: binnen enkele seconden herken je CPU-bottlenecks, geheugendruk, swap en I\/O-wachttijden. Zo interpreteer je de kolommen r, b, free, si\/so, bi\/bo en us\/sy\/id\/wa\/st op een betrouwbare manier en leid je uit patronen concrete maatregelen af \u2013 zonder giswerk, met <strong>duidelijk<\/strong> Regels.<\/p>\n\n<h2>Centrale punten<\/h2>\n\n<ul>\n  <li><strong>Wachtrij<\/strong> vs. blokkades: r geeft de CPU-belasting weer, b waarschuwt voor I\/O-wachttijden.<\/li>\n  <li><strong>Geheugen<\/strong> Realistisch beoordelen: gratis alleen is niet voldoende, het gaat om het resultaat.<\/li>\n  <li><strong>I\/O<\/strong> In het oog: bi\/bo zijn onkritisch als wa laag blijft.<\/li>\n  <li><strong>CPU-aandelen<\/strong> lees: us+sy hoog, id laag \u2192 hoge belasting.<\/li>\n  <li><strong>Basislijnen<\/strong> opstellen: waarden in het dagelijks leven vergelijken met moeilijke periodes.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/linux-vmstat-analyse-9847.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Wat laat vmstat eigenlijk zien?<\/h2>\n\n<p>Vmstat bundelt processtatussen, geheugen, swap, blok-I\/O en CPU-aandelen in een beknopte uitvoer, die binnen enkele seconden een <strong>systeemwijd<\/strong> Een goed beeld geeft. Ik bekijk eerst \u201eprocs\u201c voor r\/b, daarna \u201ememory\/swap\u201c voor free, buff, cache en si\/so. Vervolgens controleer ik \u201eio\u201c met bi\/bo en sluit ik af met \u201ecpu\u201c voor us, sy, id, wa en optioneel st. Deze volgorde helpt me om oorzaak en gevolg van elkaar te onderscheiden: een hoge r-waarde duidt op rekenbelasting, een hoge b-waarde wijst op I\/O-wachttijden, en een hoge wa-waarde koppelt CPU-inactiviteit aan I\/O-latentie. Zo zie ik of rekenwerk, geheugentekort of opslagmedia de rem zijn \u2013 en bespaar ik mezelf <strong>Omwegen<\/strong>.<\/p>\n\n<h2>Start over 60 seconden: oproepen en intervallen<\/h2>\n\n<p>Voor een momentopname vanaf het opstarten voer ik \u201evmstat\u201c zonder parameters in; voor directe analyses gebruik ik \u201evmstat 1\u201c of \u201evmstat 5 12\u201c voor twaalf meetpunten om de vijf seconden, en krijg ik een <strong>tijdsgebonden<\/strong> Rij. Belangrijk: de eerste regel geeft gemiddelde waarden weer sinds de systeemstart; ik let daarom vooral op de volgende regels. Met Delay\/Count stel ik de bemonsteringsfrequentie en de duur in, bijvoorbeeld \u201evmstat 1 30\u201c bij korte pieken. Bij onregelmatige workloads stel ik 1\u20132 seconden in, bij rustige scenario\u2019s eerder 5 seconden. Ik let op trends, niet op afzonderlijke frames, omdat patronen de ware <strong>Oorzaken<\/strong> show.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/vmstat_performance_4567.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Processen begrijpen: r en b in het dagelijks leven<\/h2>\n\n<p>De kolom r geeft het aantal gereed-voor-uitvoering-threads weer die wachten op CPU-tijd, b telt het aantal geblokkeerde threads, vaak in I\/O-wachtrij. Als r aanzienlijk hoger blijft dan het aantal fysieke kernen, dringt zich een <strong>CPU-bottleneck<\/strong> op; bij vier kernen geldt r=8 gedurende langere tijd als een duidelijk signaal. Een b-waarde groter dan 0 gedurende langere tijd duidt op trage opslagmedia, overbelaste databases of trage netwerk- of opslagpaden. Ik breng r in verband met us+sy en id: als id laag is en r hoog, heeft de CPU het zwaar; als wa hoog is en b hoog, remt de I\/O af. Zo beslis ik of ik de rekenkracht schaal, query's optimaliseer of het <strong>Opslagsysteem<\/strong> controleren.<\/p>\n\n<h2>Geheugentypen: free, buff, cache, swpd<\/h2>\n\n<p>Een lage free-waarde is normaal onder Linux, omdat de kernel het RAM-geheugen intensief als cache gebruikt, wat het openen van bestanden versnelt en echte <strong>Doorvoer<\/strong> levert op. Ik let daarom meer op swpd en de swap-streams si\/so dan op free alleen. Een hoge cache is goed, zolang si\/so bijna altijd 0 blijft; pas aanhoudende swap-activiteit duidt op echte druk. Als er bovendien latentie of zelfs OOM optreedt, grijp ik in: RAM uitbreiden, processen tijdig afslanken of cache- en JVM-groottes aanpassen. De context blijft belangrijk: workload, geheugengrootte en NUMA-indeling bepalen wat in jouw omgeving als <strong>gezond<\/strong> geldt.<\/p>\n\n<h2>Swap-activiteit: hoe dan ook indelen<\/h2>\n\n<p>De kolommen si\/so geven de constante gegevensstroom tussen het RAM-geheugen en de swap in KB\/s weer en maken de werkelijke druk op het geheugen zichtbaar, niet alleen de waargenomen druk <strong>Tekort<\/strong>. Korte pieken zijn normaal, bijvoorbeeld wanneer zelden gebruikte pagina\u2019s worden verplaatst. Het wordt kritiek als deze waarden permanent boven de 0 blijven; dat vertraagt alles, omdat elke uitwisseling extra I\/O-kosten met zich meebrengt. Hoge so-waarden duiden op actief uitwisselen, en de responstijden nemen pijnlijk toe. Op dit punt pak ik de oorzaken aan: het geheugengebruik verminderen, het RAM-geheugen uitbreiden of geheugenintensieve diensten <strong>afstemmen<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/vmstat-linux-performance-analysis-6234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Inzicht in blok-I\/O: bi en bo<\/h2>\n\n<p>Met bi\/bo kan ik de lees- en schrijfsnelheid in blokken per seconde vaststellen, maar zonder context geef ik daar geen oordeel over; doorslaggevend is de wisselwerking met <strong>wa<\/strong>. Hoge bi\/bo-waarden in combinatie met een hoge wa-waarde wijzen erop dat de opslag het niet bij kan houden. Als een hoge bi-waarde samenvalt met een database, controleer ik eerst de queryprofielen en cache-hits voordat ik hardware vervang. Voor een grondigere timing gebruik ik iostat en analyseer ik de wachtrijlengte en latenties, zodat ik <a href=\"https:\/\/webhosting.de\/nl\/server-io-wacht-analyse-iostat-vmstat-metriek-schijf\/\">I\/O-wachttijd analyseren<\/a> en knelpunten gericht kan aanpakken. Pas als wa laag blijft, maar bi\/bo blijvend explosief stijgt, denk ik na over <strong>Schalen<\/strong> van het opslagsysteem.<\/p>\n\n<h2>CPU-aandelen us, sy, id, wa, st<\/h2>\n\n<p>Hoge us-waarden bij een lage wa duiden op productief nut, terwijl hoge sy-waarden wijzen op veel kernel-overhead, zoals talloze kleine I\/O-bewerkingen of veel <strong>Contextverandering<\/strong>. Als id dicht bij 0 ligt en daar blijft, draait de CPU op de grens van zijn capaciteit; in combinatie met een hoge r-waarde duidt dit op een hoge rekenbelasting. Als wa stijgt, wacht de CPU op I\/O \u2013 hier levert het finetunen van de opslag vaak meer op dan CPU-upgrades. In VM\u2019s let ik op st (steal): hoge st-waarden duiden erop dat de hypervisor CPU-tijd afsnoept, waardoor ik met de beheerder de hostbelasting bespreek. Ik beoordeel us+sy altijd als totaal, omdat dit de actieve <strong>Arbeid<\/strong> in het systeem.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/vmstat_linux_perf_Bild_7392.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Beknopte handleiding: kolommen en richtwaarden<\/h2>\n\n<p>Ik gebruik de volgende tabel als handig geheugensteuntje wanneer ik vmstat-uitvoer voor een eerste <strong>Beoordeling<\/strong> dwarslezen.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Kolom<\/th>\n      <th>Dat betekent<\/th>\n      <th>Waar ik op let<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>r<\/td>\n      <td>Actieve discussies<\/td>\n      <td>Duurzaam &gt; Kernen \u2192 <strong>CPU-druk<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>b<\/td>\n      <td>Geblokkeerde discussies<\/td>\n      <td>Constant &gt; 0 + wa hoog \u2192 I\/O-probleem<\/td>\n    <\/tr>\n    <tr>\n      <td>gratis<\/td>\n      <td>Gratis RAM<\/td>\n      <td>Laag is ok\u00e9, zolang si\/so \u2248 0 blijft<\/td>\n    <\/tr>\n    <tr>\n      <td>buffer\/cache<\/td>\n      <td>FS-buffer\/paginacache<\/td>\n      <td>Veel cache is goed; kan worden vrijgegeven <strong>worden<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>si\/zo<\/td>\n      <td>Swap in\/uit<\/td>\n      <td>Constant &gt; 0 \u2192 werkelijke opslagedruk<\/td>\n    <\/tr>\n    <tr>\n      <td>bi\/bo<\/td>\n      <td>Blok-I\/O<\/td>\n      <td>Alleen kritisch als wa tegelijkertijd hoog is<\/td>\n    <\/tr>\n    <tr>\n      <td>us\/sy<\/td>\n      <td>Gebruiker\/Kernel<\/td>\n      <td>us+sy continu &gt; 80% \u2192 hoog <strong>Belasting<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>id<\/td>\n      <td>stationair draaien<\/td>\n      <td>Dicht bij 0 in de tijd \u2192 CPU overbelast<\/td>\n    <\/tr>\n    <tr>\n      <td>wa<\/td>\n      <td>I\/O-wacht<\/td>\n      <td>Hoog met b hoog \u2192 Opslag als oorzaak<\/td>\n    <\/tr>\n    <tr>\n      <td>st<\/td>\n      <td>Steal (VM's)<\/td>\n      <td>Hoog \u2192 Hypervisor neemt <strong>CPU<\/strong>-tijd<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Referentiepunten en langetermijnmonitoring<\/h2>\n\n<p>Ik baseer me niet op losse momentopnames, maar vergelijk dezelfde waarden met referentiewaarden uit rustige periodes, zodat ik uitschieters duidelijk kan <strong>herkennen<\/strong>. \u201evmstat 1 60\u201c geeft me een belastingsprofiel van \u00e9\u00e9n minuut, dat ik vergelijk met bekende normale fasen. Voor een historisch overzicht gebruik ik <a href=\"https:\/\/webhosting.de\/nl\/sar-sysstat-linux-servermonitoring\/\">sar\/sysstat-monitoring<\/a>, om trends over meerdere dagen te beoordelen en drempelwaarden aan te scherpen. Ik stel waarschuwingen conservatief in: r ten opzichte van Kernen, si\/so ongelijk aan 0 over meerdere intervallen, wa merkbaar verhoogd. Zo kan ik vroeg reageren, voordat gebruikers vertragingen melden en voordat <strong>Piek<\/strong>-fasen escaleren.<\/p>\n\n<h2>Vmstat in combinatie met andere tools<\/h2>\n\n<p>Ik begin met vmstat, trek conclusies op basis van de patronen en ga vervolgens gericht dieper in op de gegevens met iostat, mpstat, pidstat of applicatiestatistieken, zodat ik de oorzaken <strong>duidelijk<\/strong> toewijzen. Terwijl vmstat de I\/O-wachttijden weergeeft, meet ik met iostat de latenties en wachtrijen per apparaat. Als r wijst op een kernelbeperking, toont mpstat kernasymmetrie\u00ebn. Bij piekbelasting van processen levert <a href=\"https:\/\/webhosting.de\/nl\/pidstat-linux-procesanalyse-monitoring\/\">pidstat Procesanalyse<\/a> de meest heftige discussies over tijd. Pas de correlatie met logbestanden en applicatietimings maakt het beeld duidelijker en leidt me naar de echte <strong>Oorzaak<\/strong>.<\/p>\n\n<h2>Patronen herkennen en handelen<\/h2>\n\n<p>Als ik zie dat r hoog is, id laag en wa gematigd, dan optimaliseert de applicatie vaak op een manier die te rekenintensief is. Daarom controleer ik de code of de mate van parallelliteit en plan ik de CPU-bronnen voordat ik <strong>Hardware<\/strong> vereis. Als b, wa en bi\/bo samen hoog zijn, overweeg ik opslagoptimalisatie, query-optimalisatie en caching. Bij een lage free-waarde met si\/so groter dan 0 verlaag ik het geheugengebruik, stream ik resultaten of verhoog ik het RAM-geheugen. Als us matig en sy zeer hoog zijn, kijk ik naar pakketfilters, bestandssysteemopties of stuurprogramma's. Met deze checklist handel ik snel en besteed ik mijn tijd daar waar die het meest <strong>telt<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/vmstat-linux-analyst-7645.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Meetfouten voorkomen: steekproeven, eenheden, eerste regel<\/h2>\n\n<p>Ik neem de eerste regel bewust niet mee bij het beoordelen van acute storingen, omdat deze sinds het opstarten wordt gemiddeld en pieken volledig afvlakt. Bovendien stem ik de bemonsteringsfrequentie af op de hypothese over de oorzaak: CPU-pieken registreer ik met intervallen van 1 seconde, langzame geheugenlekken met intervallen van 5\u201310 seconden. Ik let op de eenheden: si\/so zijn KB\/s, bi\/bo \u201eblokken\/s\u201c (historisch gezien 1 KB per blok, variabel afhankelijk van de vmstat-versie). Ik controleer of \u201evmstat -w\u201c (brede uitvoer) het afkappen van kolommen voorkomt en of veranderingen in de kloksnelheid (P-states, Turbo) de waarneming van de belasting op korte termijn be\u00efnvloeden. Ik stem de metingen af op pieken in de applicatie, in plaats van blindelings naar \u201ehele minuten\u201c te kijken.<\/p>\n\n<h2>Systeemsectie ontcijferen: in en cs<\/h2>\n\n<p>Naast procs\/memory\/swap\/io\/cpu geeft vmstat ook \u201esystem\u201c weer: <strong>in<\/strong> (onderbrekingen per seconde) en <strong>cs<\/strong> (Contextwisselingen per seconde). Deze twee waarden geven me veel informatie over de overhead van de kernel.<\/p>\n<ul>\n  <li>cs erg hoog bij een matig werkbelasting: thread-flutter, te kleine worker-batches of lock-contention. Ik vergroot de batchgroottes, pas de parallelliteit aan (threadpools) en controleer scheduler-\/mutex-hotspots.<\/li>\n  <li>een plotselinge piek: een stortvloed aan netwerk- of opslaginterrupts, NAPI\/polling-effecten of timer-interrupts. Ik vergelijk dit met het sy-aandeel en de iostat-resultaten om stuurprogramma\u2019s of netwerkpaden te controleren.<\/li>\n  <li>cs evenredig aan r: Dit duidt op een voortdurende druk om van context te wisselen als gevolg van overmatige parallelliteit. Ik beperk de actieve parallelliteit of bind hot-threads aan cores.<\/li>\n<\/ul>\n<p>Ik breng in\/cs altijd in verband met sy en b\/wa: alleen in combinatie ontstaat een duidelijk beeld of kernelwerk zinvol is (bijv. doorvoer) of louter overhead is.<\/p>\n\n<h2>Handige vmstat-varianten en opties<\/h2>\n\n<p>Ik gebruik vmstat op een flexibele manier om extra inzichten te krijgen zonder van tool te hoeven wisselen:<\/p>\n<ul>\n  <li><strong>vmstat -s<\/strong>: Totaaltellers (bijv. processen die sinds het opstarten zijn gestart, major\/minor page faults). Ideaal om lekken of het aantal gevallen over bepaalde tijdsperioden te vergelijken.<\/li>\n  <li><strong>vmstat -m<\/strong>: Slab-gebruik \u2013 helpt om kernelcaches (Dentry\/Inode, netwerk) te classificeren als RAM-verbruikers.<\/li>\n  <li><strong>vmstat -d<\/strong>: Schijfgebeurtenissen op totaalniveau. Geen vervanging voor iostat, maar wel handig voor een snelle reality-check.<\/li>\n  <li><strong>vmstat -S M<\/strong>: Eenheden omzetten (M\/K) om getallen beter leesbaar te maken.<\/li>\n  <li><strong>vmstat -w<\/strong>: Bredere kolommen voorkomen dat grote getallenkolommen worden afgekapt.<\/li>\n<\/ul>\n<p>Ik combineer deze varianten met korte tussenpozen, zodat ik geen evenementen mis en toch het overzicht behoud.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/vmstat_linux_analyse_3947.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Containers, VM\u2019s en cgroups: bijzonderheden<\/h2>\n\n<p>In containers interpreteer ik vmstat met de nodige voorzichtigheid: veel kernelgegevens gelden voor de hele host, terwijl limieten afkomstig zijn van Cgroups. Hoge r-waarden in een container weerspiegelen het beeld vanuit de namespace, maar de werkelijke CPU-tijd kan worden beperkt door CPU-quota\u2019s of CPU-shares. Ik baseer me op <strong>st<\/strong> (Steal) in VM\u2019s: een hoge st-waarde betekent dat de hypervisor mij tijd afneemt \u2013 dan helpt zelfs een perfecte app-optimalisatie weinig, zolang de host overboekt is. Bij geheugenlimieten in Cgroups kan si\/so uitblijven, hoewel de container tegen de limiet \u201eaan het spartelen\u201c is (OOM-kills in plaats van swap). Ik controleer daarom ook OOM-logs en Cgroup-statistieken en vergelijk vmstat-overzichten met de limieten.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/vmstat-linux-analyst-7645.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NUMA en affiniteit: wanneer lokaliteit telt<\/h2>\n\n<p>Op NUMA-hosts controleer ik r en us\/sy per kern (met mpstat) en kijk ik of afzonderlijke sockets \u201eoververhit raken\u201c, terwijl andere inactief zijn. Een ongeschikte geheugenlocatie leidt tot meer cs\/sy en stijgingen in b\/wa als gevolg van geheugentoegangen op afstand. Ik test CPU- en geheugenaffiniteit (cpuset, numactl), stel grote heaps in op \u201einterleaved\u201c of \u2018strictly local\u2019 en zorg ervoor dat hot-threads draaien op de plek waar hun gegevensvoetafdruk zich bevindt. Een stabiele NUMA-indeling egaliseert cs, vermindert wa-uitval en verhoogt de <strong>Planbaarheid<\/strong> onder belasting.<\/p>\n\n<h2>Misvattingen voorkomen: wa en b zijn meer dan alleen \u201etrage gegevensdragers\u201c<\/h2>\n\n<p>wa stijgt niet alleen bij klassieke schijflatenties: ook NFS\/netwerken met hoge latentie, verzadigde objectopslag, blokkerende cloudvolumes of trage page-cache-writebacks drijven wa omhoog. b telt taken die zich in een ononderbreekbare slaapstand (D-state) bevinden \u2013 hieronder vallen ook vastlopers in stuurprogramma\u2019s, netwerkpaden of bestandssysteemvergrendelingen. Daarom beoordeel ik wa\/b nooit afzonderlijk, maar altijd in combinatie met bi\/bo en applicatietimings. Als wa hoog is, maar bi\/bo laag, is er vaak sprake van een <strong>Afhankelijkheid van wachttijden<\/strong> die verder gaan dan louter de doorvoercapaciteit van de apparaten (bijv. locking, remote I\/O, writeback-opstopping).<\/p>\n\n<h2>Tuning met gezond verstand: Swappiness, Writeback, Scheduler<\/h2>\n\n<p>Ik pas Kernel-Tuner pas aan na een meting en met een rollback-plan:<\/p>\n<ul>\n  <li><strong>vm.swappiness<\/strong>: Een lagere waarde remt proactief swappen af, wat goed is voor apps waarbij de latentie van cruciaal belang is \u2013 een te lage waarde kan de druk op de paginacache verhogen.<\/li>\n  <li><strong>vm.dirty_background_ratio \/ vm.dirty_ratio<\/strong> (of *_bytes): be\u00efnvloeden het tijdstip van writeback. Te hoge waarden leiden tot lange schrijfbursts (wa-pieken), te lage waarden zorgen voor meer voortdurende kleine flushes (sy\/bo stijgen).<\/li>\n  <li><strong>I\/O-planner\/wachtrijdiepte<\/strong>: Op NVMe andere instellingen dan op HDD\/RAID. Ik meet de afwegingen tussen latentie en doorvoersnelheid met iostat voordat ik wijzigingen aanbreng.<\/li>\n  <li><strong>Netwerkpaden<\/strong>: Er komen veel kleine pakketjes\/interrupts binnen in \/cs\/sy. Grove afstemmingsopties zijn GRO\/LRO, RPS\/RFS, IRQ-affiniteit \u2013 ik meet de situatie voor en na.<\/li>\n<\/ul>\n<p>Mijn doel is stabiele, voorspelbare grafieken in vmstat: us\/sy stabieler, wa\/b lager, si\/so zo dicht mogelijk bij 0. Pas dan breid ik de hardware uit.<\/p>\n\n<h2>Playbook: analyse in 3 minuten met vmstat<\/h2>\n\n<ul>\n  <li>0:00\u20130:30 \u2013 \u201evmstat 1 30\u201c: negeer de eerste regel, bekijk vervolgens r\/b, us\/sy\/id\/wa. Vraag: CPU-limiet (r hoog, id laag) of I\/O-limiet (b\/wa hoog)?<\/li>\n  <li>0:30\u20131:00 \u2013 Weergave van de opslagtank: controleer swpd en si\/so. Is si\/so continu &gt; 0? \u2192 echte opslagtankdruk. Free is van ondergeschikt belang.<\/li>\n  <li>1:00\u20131:30 \u2013 I\/O-context: bi\/bo versus wa. Hoge bi\/bo zonder wa? \u2192 I\/O wordt weggestopt. Hoge wa bij gematigde bi\/bo? \u2192 Latentie\/Lock\/Remote-I\/O.<\/li>\n  <li>1:30\u20132:00 \u2013 systeemgedeelte: in\/cs in verhouding tot sy. cs erg hoog? \u2192 Controleer op contextwisselingsdruk, paralleliteit\/locking.<\/li>\n  <li>2:00\u20133:00 \u2013 Hypothese vaststellen en het juiste hulpmiddel kiezen: iostat bij I\/O-index, mpstat bij kernasymmetrie\u00ebn, pidstat bij proces-hotspots. Pas daarna afstemmen\/schalen.<\/li>\n<\/ul>\n\n<h2>Uitgebreide voorbeelden uit de praktijk<\/h2>\n\n<ul>\n  <li><strong>CPU-verzadiging zonder hoge r<\/strong>: us+sy bij 90%+, id \u2248 0, maar r is matig \u2192 single-thread-hotspot of affiniteitsprobleem. Oplossing: het hot-pad paralleliseren, core-pinning controleren.<\/li>\n  <li><strong>Swap-Thrash<\/strong>: in beide gevallen tegelijk duidelijk &gt; 0, b\/wa stijgen, us daalt \u2192 RAM veel te klein of heap verkeerd gedimensioneerd. Maatregelen: RAM vergroten, werkset verkleinen, swappiness aanpassen.<\/li>\n  <li><strong>Kernel-overhead<\/strong>: sy hoog, cs\/in hoog, us matig \u2192 veel kleine syscalls\/I\/O. Oplossing: batchen, aantal syscalls verminderen, mount-opties van het bestandssysteem controleren.<\/li>\n  <li><strong>Writeback-opstopping<\/strong>: wa hoog, bo hoog, korte golven \u2192 dirty-grenzen te hoog, opslaglatentie varieert. Writeback-tuning en I\/O-scheduler controleren.<\/li>\n  <li><strong>Druk om te virtualiseren<\/strong>: st zichtbaar, r schommelt, id \u201espringt\u201c \u2192 Host deelt CPU. Oplossing: vCPU-toewijzing\/plaatsing controleren, overcommit verminderen.<\/li>\n<\/ul>\n\n<h2>De beperkingen van vmstat kennen<\/h2>\n\n<p>Vmstat is een uitstekende <strong>Vroegtijdige waarschuwingssensor<\/strong>, maar geen microscoop. Het laat me zien dat er iets niet klopt en waar precies \u2013 niet het specifieke \u2018schuldige\u2019 bestand, de query of de thread. Daarom ga ik na de vmstat-diagnose consequent aan de slag met diepgaande tools, bevestig ik hypothesen vanuit verschillende invalshoeken en verander ik vervolgens slechts \u00e9\u00e9n ding tegelijk. Zo blijven verbeteringen meetbaar en reproduceerbaar.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/vmstat_linux_analyse_3947.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Samenvatting uit de praktijk<\/h2>\n\n<p>Met vmstat kan ik binnen enkele seconden zien of de CPU, het RAM, de swap of de I\/O de systeemprestaties vertragen, door de waarden van r, b, si\/so, bi\/bo en us\/sy\/id\/wa\/st in combinatie te bekijken <strong>lees<\/strong>. Ik analyseer trends in plaats van individuele waarden, vergelijk deze met referentiewaarden en raadpleeg indien nodig iostat, mpstat, pidstat en historische metingen. Bij acute storingen negeer ik de eerste regel en concentreer ik me op de volgende regels met een vaste bemonsteringsfrequentie. Ik neem datagestuurde beslissingen: r ten opzichte van kerns, si\/so blijvend ongelijk aan 0, wa aanhoudend verhoogd, us+sy dicht bij volledige belasting. Zo leid ik snel concrete maatregelen af en houd ik systemen merkbaar <strong>reactief<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>Leer hoe je vmstat in Linux correct kunt interpreteren om CPU-, geheugen- en I\/O-bottlenecks te herkennen en je prestatieanalyse te optimaliseren met het trefwoord vmstat linux.<\/p>","protected":false},"author":1,"featured_media":21476,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[780],"tags":[],"class_list":["post-21483","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"79","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"vmstat linux","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"21476","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/21483","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/comments?post=21483"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/21483\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/21476"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=21483"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=21483"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=21483"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}