{"id":19334,"date":"2026-05-14T12:39:05","date_gmt":"2026-05-14T10:39:05","guid":{"rendered":"https:\/\/webhosting.de\/server-io-wait-analyse-iostat-vmstat-metrics-disk\/"},"modified":"2026-05-14T12:39:05","modified_gmt":"2026-05-14T10:39:05","slug":"server-io-wacht-analyse-iostat-vmstat-metriek-schijf","status":"publish","type":"post","link":"https:\/\/webhosting.de\/nl\/server-io-wait-analyse-iostat-vmstat-metrics-disk\/","title":{"rendered":"Server I\/O wachttijdanalyse met iostat en vmstat: Linux serverstatistieken optimaliseren"},"content":{"rendered":"<p>Ik laat stap voor stap zien hoe de I\/O wachttijd analyse met iostat en vmstat knelpunten zichtbaar maakt en welke Linux server metrieken meetellen voor snelle responstijden. Daarbij stel ik duidelijke drempels in, interpreteer ik typische patronen en stel ik concrete maatregelen voor om te optimaliseren <strong>I\/O<\/strong> en <strong>CPU<\/strong> in.<\/p>\n\n<h2>Centrale punten<\/h2>\n<ul>\n  <li><strong>iostat<\/strong> en <strong>vmstat<\/strong> een complementair beeld geven van CPU- en opslagbelasting.<\/li>\n  <li><strong>wa<\/strong> via 15-20% en <strong>%utiel<\/strong> via 80% laten een I\/O-knelpunt zien.<\/li>\n  <li><strong>wacht op<\/strong> en <strong>avgqu-sz<\/strong> latentie en wachtrijen uitleggen.<\/li>\n  <li><strong>mpstat<\/strong> detecteert ongelijk verdeelde belasting over CPU-kernen.<\/li>\n  <li><strong>Afstemmen<\/strong> varieert van <strong>MySQL<\/strong> naar kernelparameters en opslag.<\/li>\n<\/ul>\n\n<h2>Wat betekent I\/O Wait op Linux-servers?<\/h2>\n<p>Onder I\/O wait wacht de CPU inactief omdat hij wacht op langzamere geheugen- of netwerkapparaten, wat kan worden gezien als <strong>wa<\/strong>-waarde in tools zoals top of vmstat. Ik evalueer deze verhouding als de tijd waarin threads blokkeren en verzoeken later worden afgerond, wat gebruikers direct ervaren als traagheid. Waarden boven 10-20% duiden vaak op een volledig gebruikte <strong>Opslag<\/strong>-subsysteem, bijvoorbeeld wanneer HDD's, RAID-arrays of NFS-mounts volledig worden gebruikt. In hostingopstellingen met databases zorgen niet-ge\u00efndexeerde query's en schrijfpieken voor onnodige wachttijden op de <strong>Schijf<\/strong>. Als je de concepten wilt opfrissen, kun je de basis vinden op <a href=\"https:\/\/webhosting.de\/nl\/io-wait-begrijpen-geheugenbottleneck-oplossen-optimalisatie\/\">I\/O-wacht begrijpen<\/a>, voordat ik naar de praktijk ga.<\/p>\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\/05\/linux-server-io-8592.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Snel aan de slag: vmstat correct lezen<\/h2>\n<p>Met vmstat kan ik de belangrijkste controleren <strong>Linux<\/strong>-en zonder veel moeite de eerste patronen herkennen. De aanroep vmstat 1 10 levert tien momentopnames op waarbij ik vooral let op de kolommen wa (I\/O wait), bi\/bo (block I\/O) en si\/so (swap). Voor mij duiden hoge bo waarden met tegelijkertijd toenemende wa op veel blokkerende schrijftoegang, wat vaak duidt op bufferlimieten of trage media. Als si\/so op nul blijft, maar wa aanzienlijk stijgt, is het vermoeden van pure <strong>Opslag<\/strong>-limiet. In multi-core hosts combineer ik vmstat met mpstat -P ALL 1, omdat I\/O-wacht vaak alleen individuele cores be\u00efnvloedt en daarom gemiddeld onschuldiger lijkt dan het in werkelijkheid is.<\/p>\n\n<h2>CPU fijn beeld: us\/sy\/st, run queue en context switch<\/h2>\n<p>Met vmstat en mpstat lees ik meer dan alleen <strong>wa<\/strong>: Hoog <strong>us<\/strong>Het \"reken-zware\" applicatiewerk wordt in de volgende secties getoond, <strong>sy<\/strong> geeft kernel\/driver-werk aan, bijvoorbeeld met intensieve <strong>I\/O<\/strong>. In gevirtualiseerde omgevingen let ik op <strong>st<\/strong> (Stelen): Hoge st-waarden betekenen dat de VM CPU-tijd verliest, waardoor latenties kunstmatig worden opgeblazen met een identiek I\/O-patroon. Ik vergelijk ook de run queue (<strong>r<\/strong> in vmstat) met het aantal CPU's: een permanent hogere r dan het aantal CPU's duidt op congestie op de CPU, niet op de <strong>Opslag<\/strong>. Veel contextveranderingen (<strong>cs<\/strong>) in combinatie met kleine synchrone schrijfsessies zijn een indicator van babbelzieke I\/O-patronen. Op deze manier voorkom ik dat CPU-tekort verkeerd ge\u00efnterpreteerd wordt als een I\/O-probleem.<\/p>\n\n<h2>iostat grondig begrijpen: belangrijke statistieken<\/h2>\n<p>iostat -x 1 geeft me uitgebreid <strong>Schijf<\/strong>-metingen die latency, utilisation en queues duidelijk beschrijven. Ik start de meting voor belastingspieken en correleer %util, await, svctm en avgqu-sz om oorzaak en gevolg te onderscheiden. Als %util stijgt naar 90-100%, terwijl await en avgqu-sz ook stijgen, zie ik een verzadigde <strong>Plaat<\/strong> of een beperkt volume. Als await hoge waarden laat zien met gematigde %util, controleer ik op interferentie door caching, controllerlimieten of individuele grote verzoeken. r\/s en w\/s brengen frequentie in beeld, terwijl MB_read en MB_wrtn het volume verklaren, wat me belangrijke vergelijkende waarden geeft voor dedicated SSD en NVMe opstellingen.<\/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\/05\/linuxserveroptiokoni7553.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NVMe, SATA en RAID: wat %util, await en wachtrijdiepte betekenen<\/h2>\n<p>Ik maak een strikt onderscheid tussen mediatypes: <strong>HDD<\/strong> hoger tonen <strong>wacht op<\/strong>-waarden, zelfs met een matige cue, omdat hoofdbewegingen domineren. <strong>SSD<\/strong>\/NVMe goed schalen met parallellisme, daarom is een hogere <strong>avgqu-sz<\/strong> kan normaal zijn zolang <strong>wacht op<\/strong> binnen de limieten blijft. Op NVMe met meerdere wachtrijen voor indiening\/voltooiing lees ik %util voorzichtiger: individuele apparaten kunnen al aan de limiet zitten bij 60-70% als de app niet genoeg parallellisme genereert of de wachtrijdiepte (<strong>nr_aanvragen<\/strong>, <strong>wachtrij_diepte<\/strong>) is te klein. In de <strong>RAID<\/strong> Ik controleer of het strooien van willekeurige I\/O te kleine stripe-groottes tegenkomt; dan <strong>wacht op<\/strong> en <strong>%utiel<\/strong> ongelijkmatig op de lidschijven. Ik kijk daarom naar iostat per aangesloten apparaat, niet alleen op het samengestelde volume, om hotspots zichtbaar te maken. Voor loggestructureerde lagen (bijvoorbeeld copy-on-write) verwacht ik iets hogere latencies voor writes, maar compenseer dit met vergrote writeback windows of app-side batching.<\/p>\n\n<h2>Diagnostische workflow voor lange wachttijden<\/h2>\n<p>Ik start elke analyse parallel met vmstat 1 en iostat -x 1 zodat ik de CPU toestanden en apparaatstatus synchroon kan zien en aan tijd kan toewijzen. Vervolgens gebruik ik mpstat -P ALL 1 om te controleren of individuele cores ongebruikelijk hoog draaien. <strong>wa<\/strong> wat onjuist ge\u00efnterpreteerde gemiddelde waarden voorkomt. Als er aanwijzingen zijn voor een oorzaak, gebruik ik pidstat -d of iotop om precies te zien welke PID de meeste I\/O-shares gebruikt. In hostingomgevingen met databases maak ik eerst onderscheid tussen lees- en schrijfpieken, omdat terugschrijfstrategie\u00ebn en fsync-patronen heel verschillende symptomen genereren en dus gebruikt kunnen worden voor gerichte <strong>Maatregelen<\/strong> het mogelijk maken. Voor meer diepgaande vragen over opslag is een overzicht zoals dat op <a href=\"https:\/\/webhosting.de\/nl\/io-bottleneck-hosting-latentie-analyse-optimalisatie-opslag\/\">I\/O knelpunt in hosting<\/a>, voordat ik de kernel of het bestandssysteem aanpas.<\/p>\n\n<h2>Duidelijke afbakening tussen virtualisatie en containers<\/h2>\n<p>In VM's beschouw ik <strong>wa<\/strong> samen met <strong>st<\/strong> (Stelen) en daarnaast meten op de hypervisor, omdat alleen daar de echte apparaten en <strong>Cues<\/strong> zichtbaar zijn. Opslagaggregaties (thin provisioning, deduperen, snapshots) verplaatsen latentiepieken naar beneden in de stack - in de VM heeft dit het volgende effect <strong>wacht op<\/strong> springt, terwijl %util onopvallend blijft. In containers beperk of ontkoppel ik <strong>I\/O<\/strong> met Cgroup-regels (bijv. IOPS-\/doorvoerlimieten) om <strong>Luidruchtige buren<\/strong> om ze te temmen. Ik documenteer de limieten per service zodat gemeten waarden reproduceerbaar zijn en alarmen hun context behouden. Belangrijk: Een hoge <strong>wa<\/strong> in de VM kan worden geactiveerd door host-brede back-ups, scrubs of rebuilds - ik correleer tijden met hostjobs voordat ik de app aanraak.<\/p>\n\n<h2>Grenzen, drempels en volgende stappen<\/h2>\n<p>Ik gebruik een paar duidelijke drempelwaarden om te beslissen of er echt een knelpunt is en welke actie ik moet ondernemen om de prestaties merkbaar te stabiliseren. Ik houd rekening met het type media, de werklast en de latentievereisten, omdat dezelfde cijfers op HDD en NVMe verschillende implicaties hebben. Ik gebruik de volgende tabel als een snelle richtlijn die ik gebruik in mijn playbooks. Ik meet meerdere keren over minuten en onder belasting, zodat uitschieters geen vals alarm genereren en ik trends kan herkennen. Ik gebruik dit als basis voor gerichte actie in plaats van reflexmatig hardware te vervangen of <strong>Parameters<\/strong> massaal.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Metriek<\/th>\n      <th>Drempel<\/th>\n      <th>Interpretatie<\/th>\n      <th>Volgende stappen<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>wa<\/strong> (vmstat)<\/td>\n      <td>&gt; 15-20%<\/td>\n      <td>Aanzienlijke I\/O-wachttijd<\/td>\n      <td>Controleer iostat; zoek de oorzaak met pidstat\/iotop; analyseer caching en schrijven<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>%utiel<\/strong> (iostat)<\/td>\n      <td>&gt; 80-90%<\/td>\n      <td>Gebruikt apparaat<\/td>\n      <td>correleer await\/avgqu-sz; controleer wachtrijdiepte, planner, RAID en SSD\/NVMe<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>wacht op<\/strong> (ms)<\/td>\n      <td>&gt; 10-20 ms SSD, &gt; 30-50 ms HDD<\/td>\n      <td>Verhoogde latentie<\/td>\n      <td>Onderscheid maken tussen random vs. sequentieel; bestandssysteemopties aanpassen, writeback, journaling<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>avgqu-sz<\/strong><\/td>\n      <td>&gt; 1-2 aanhoudend<\/td>\n      <td>Wachtrij groeit<\/td>\n      <td>Parallellisme afremmen\/verhogen; I\/O-patroon van de app optimaliseren; controllerlimieten controleren<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>si\/zo<\/strong> (vmstat)<\/td>\n      <td>&gt; 0 onder belasting<\/td>\n      <td>Knelpunt in opslag<\/td>\n      <td>RAM verhogen; query\/cache afstellen; swappiness\/geheugenlimieten controleren<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/server-metrics-optimization-8421.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Oorzaken in de stack: DB, bestandssysteem, virtualisatie<\/h2>\n<p>Bij databases zie ik vaak niet-ge\u00efndexeerde joins, buffers die te klein zijn en overmatige fsync-aanroepen als de werkelijke <strong>Oorzaken<\/strong> voor hoge wachtwaarden. Ik controleer queryplannen, activeer logs voor langzame verklaringen en pas maten zoals InnoDB bufferpool, logbestandsgroottes en open bestanden objectief aan. Op bestandssysteemniveau kijk ik naar mount-opties, journaalmodi en uitlijning op de RAID-strip, omdat de verkeerde combinaties ervoor zorgen dat wachttijden exploderen. In gevirtualiseerde opstellingen vertrouw ik niet alleen op metingen in de VM, maar kijk ik naar de host, omdat dit de plaats is waar de echte blokapparaten en <strong>Cues<\/strong> zichtbaar worden. Hierdoor kan ik de effecten van deduplicatie, thin provisioning of naburige VM's duidelijk scheiden van de applicatiepatronen.<\/p>\n\n<h2>Bestandssysteem en koppelopties in detail<\/h2>\n<p>Ik evalueer bestandssystemen in het licht van de werklast: <strong>ext4<\/strong> in geordende of terugschrijfmodus minimaliseert barri\u00e8res voor schrijfintensiteit, terwijl <strong>XFS<\/strong> scoort met zijn logontwerp voor parallelle werklasten. Opties zoals <strong>noatime<\/strong> of <strong>relatime<\/strong> het schrijven van metadata verminderen, <strong>luiheid<\/strong> verplaatst timestamp updates naar de writeback in bundels. Voor journaling controleer ik de commit intervallen (bijv. commit=) en controleer ik of geforceerde flushes (barri\u00e8res) worden verergerd door controller cache beleid. Op RAID let ik op schone uitlijning op de stripe (Parted\/FDISK met 1MiB start), anders <strong>wacht op<\/strong> door Read-Modify-Write, zelfs met zogenaamd sequenti\u00eble patronen. Voor databases gebruik ik vaak O_DIRECT of direct log flush strategie\u00ebn - maar alleen na meting, omdat de cache van het bestandssysteem de leeslast drastisch kan verminderen als de werkset erin past.<\/p>\n\n<h2>Tuning: van de kernel tot de app<\/h2>\n<p>Ik begin met eenvoudige overwinningen, bijvoorbeeld query indexering, batch schrijven en een verstandige connection pooling configuratie, voordat ik op systeemniveau begin. Voor writeback pas ik vm.dirty_background_ratio, vm.dirty_ratio en vm.dirty_expire_centisecs gecontroleerd aan zodat het systeem contigu schrijft en minder blokkeringen genereert zonder het geheugen te verstoppen. Voor blokapparaten controleer ik de I\/O scheduler, wachtrijdiepte en read-ahead omdat deze parameters direct de latentie en doorvoer bepalen. Op RAID-controllers stem ik de streepgrootte en het cachebeleid af, terwijl ik op <strong>SSD<\/strong>\/NVMe voor firmware, TRIM en consistente overprovisioning-instellingen. Na elke wijziging controleer ik met vmstat en iostat gedurende enkele minuten of de wachttijd daalt en %util stabiel blijft voordat ik de volgende stap neem.<\/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\/05\/TechOfficeServerAnalyse4102.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Interrupts, NUMA en affiniteiten<\/h2>\n<p>Ik houd IRQ-belasting en NUMA-topologie in de gaten omdat beide een merkbaar effect hebben op latencies. <strong>NVMe<\/strong>-Ik bind interrupts aan de CPU's van het NUMA-domein van de controller via affiniteit zodat gegevenspaden kort blijven. Als de IRQ storm op een core draait, zie ik hoge <strong>sy<\/strong> en de rest van de CPU's lijken inactief te zijn; <strong>mpstat<\/strong> legt dit bloot. Ik sta irqbalance alleen toe als de distributie overeenkomt met de hardware - anders stel ik specifieke affiniteiten in. Ik controleer ook of de applicatie en zijn <strong>I\/O<\/strong> werken in dezelfde NUMA-zone (opslaglocatie), omdat cross-socket toegang wachttijden veroorzaakt in <strong>wacht op<\/strong> kan worden gemaskeerd.<\/p>\n\n<h2>Metingen automatiseren en visualiseren<\/h2>\n<p>Om er zeker van te zijn dat ik trends herken, automatiseer ik metingen en integreer ik iostat\/vmstat in monitoring tools, die gebruikt kunnen worden om historische gegevens te analyseren. <strong>Gegevens<\/strong> opslaan. Ik stel alarmen conservatief in, bijvoorbeeld van wa &gt; 15% over meerdere intervallen, gecombineerd met drempels voor await en %util om vals alarm te voorkomen. Voor algemene statistieken gebruik ik dashboards die CPU, opslag, netwerk en app statistieken naast elkaar zetten zodat correlaties direct zichtbaar zijn. Als je een inleiding tot statistieken nodig hebt, kun je ze vinden op <a href=\"https:\/\/webhosting.de\/nl\/server-statistieken-cpu-idle-load-wacht-analyse-serverboost\/\">Servergegevens<\/a> compacte context voor het dagelijkse werk. Ik vind het belangrijk om een herhaalbaar proces te hebben: meten, een hypothese vormen, aanpassingen maken, opnieuw meten en de resultaten analyseren. <strong>Resultaten<\/strong> document.<\/p>\n\n<h2>Reproduceerbare belastingstests met fio<\/h2>\n<p>Als ik geen echte belasting heb of hypotheses wil verifi\u00ebren, gebruik ik kortstondige <strong>fio<\/strong>-tests. Ik simuleer representatieve patronen (bijv. 4k willekeurig lezen, 64k sequentieel schrijven, gemengde 70\/30 profielen) en varieer <strong>iodepth<\/strong>, om het sweet spot-venster in te stellen tussen <strong>wacht op<\/strong> en doorvoer. Ik maak een strikte scheiding tussen testpaden en productiegegevens en noteer randvoorwaarden (bestandssysteem, koppelopties, scheduler, wachtrijdiepte) zodat ik de resultaten correct kan categoriseren. Na het afstemmen worden dezelfde tests gebruikt als regressiecontrole; alleen als <strong>wacht op<\/strong> en <strong>%utiel<\/strong> er consistent beter uitzien, breng ik wijzigingen aan op het oppervlak.<\/p>\n\n<h2>Foutpatronen herkennen: typische patronen<\/h2>\n<p>Als ik een hoge wa waarneem met tegelijkertijd een hoge %utile en een stijgende avgqu-sz, spreekt alles in het voordeel van verzadiging op de <strong>Apparaat<\/strong>, d.w.z. echte fysieke grenzen. Hoge wachtwaarden met een matige %util duiden meestal op eigenaardigheden van de controller of caching, zoals barri\u00e8res, doorschrijven of sporadische flushes. Stijgende si\/so waarden samen met dips in de cache duiden duidelijk op een gebrek aan RAM, waardoor I\/O kunstmatig wordt opgeblazen en wachttijden toenemen. Als de schijf onopvallend blijft, maar de app grote, sync-zware schrijfacties in beeld brengt, verschuif ik het werk naar asynchroon schrijven, pipelining of <strong>Batch<\/strong>-mechanismen. In NFS of netwerkopslag opstellingen controleer ik ook latency, MTU, retransmits en server-side caching, omdat netwerktijd hier direct gemaskeerd wordt als I\/O latency.<\/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\/05\/server_metrics_analysis_1423.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NFS\/iSCSI en gedistribueerde opslag<\/h2>\n<p>Op <strong>NFS<\/strong> en iSCSI maak ik onderscheid tussen apparaat en netwerkpad: <strong>iostat<\/strong> laat alleen zien wat de bloklaag ziet - ik herken ook retransmits, latenties en vensterproblemen via netwerkmetriek. Hoog <strong>wacht op<\/strong> met matige <strong>%utiel<\/strong> op het virtuele block device is typisch wanneer het netwerk vastloopt of de cache aan de serverkant afkoelt. Voor NFS controleer ik mount opties (rsize\/wsize, proto, sync\/async) en de serverkant (threads, export policies, cache), voor iSCSI de sessie en wachtrij parameters. Ik plan onderhoudsvensters voor servertaken (scrubs, rebuilds, rebalancing) zodat ze de gedeelde opslag niet verzadigen op piekmomenten en de server daardoor onbeschikbaar wordt. <strong>wa<\/strong> op alle klanten.<\/p>\n\n<h2>Praktische voorbeelden: drie korte scenario's<\/h2>\n<h3>Blogcluster met schrijftips<\/h3>\n<p>Op prime time nemen comments en cache invalidate toe, waarna await en avgqu-sz in iostat aanzienlijk toenemen, terwijl %util blijft hangen op 95%. Ik verhoog voorzichtig de writeback-parameters, optimaliseer cache-invalidatie op padniveau en verhoog de InnoDB logbuffer zodat er minder kleine sync-schrijvingen zijn. Hierna daalt de wachttijd meetbaar, de bo-waarden blijven hoog, maar de wa daalt, wat de responstijden onmiddellijk verlaagt. Tegelijkertijd vervang ik individuele HDD's door SSD's voor het journaal, wat de bottleneck nog verder verkleint. Het patroon laat zien hoe <strong>Batch<\/strong>-Combineer schrijven en sneller journaling.<\/p>\n<h3>Winkelen met leespieken en zoekindices<\/h3>\n<p>Promoties genereren zware leesbelasting, r\/s schiet omhoog, wachttijd blijft matig, maar de app reageert nog steeds traag op filternavigatie. Ik herken veel ongebufferde query's zonder geschikte indices die de werkset van de bestandssysteemcache overschrijden. Met gerichte indexering en query herschrijving daalt de r\/s, de hits zitten vaker in de cache en iostat bevestigt een lagere MB_read met dezelfde doorvoer. Tegelijkertijd verhoog ik read-ahead iets om sequenti\u00eble scans effici\u00ebnter te serveren, wat de latencies verder verlaagt. Zo controleer ik dat <strong>Lees<\/strong>-patronen leiden weer tot cache-hits.<\/p>\n<h3>VM-host met \u201eNoisy Neighbour\u201c<\/h3>\n<p>In individuele VM's toont top hoge wa, maar iostat in de VM ziet alleen virtuele apparaten met misleidend gebruik. Ik meet ook op de hypervisor, zie verzadigde echte block devices en identificeer een naburige VM met agressieve back-ups als de oorzaak. Bandbreedtelimieten en aangepaste back-upvensters stabiliseren de wachttijd en %util in de hele host. Vervolgens meet ik opnieuw in de VM en op de host om het effect aan beide kanten te bevestigen en te voorkomen. Dit bevestigt dat echte <strong>Apparaten<\/strong>-Metrics tonen altijd de waarheid bij de host.<\/p>\n\n<h2>Checklist voor het volgende incident<\/h2>\n<p>Ik start eerst logs en metingen zodat er geen signalen verloren gaan en laat vmstat 1 en iostat -x 1 enkele minuten draaien. Vervolgens correleer ik pieken in de tijd met app events en systeem timers voordat ik individuele processen opspoor met pidstat -d en hypotheses formuleer. De volgende stap controleert geheugen, swap en cache hits zodat RAM tekorten niet ten onrechte worden herkend als <strong>Schijf<\/strong>-probleem verschijnt. Pas als ik de oorzaak heb ge\u00efsoleerd, verander ik precies \u00e9\u00e9n ding, log de instelling en evalueer het effect op await, %util en wa. Op deze manier houd ik de analyse reproduceerbaar, leer ik van elk incident en verkort ik de tijd tot de <strong>Oplossing<\/strong> duidelijk.<\/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\/05\/serveranalyse-linuxmetrics-4581.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Vaak verkeerde interpretaties en struikelblokken<\/h2>\n<p>Ik laat me niet misleiden door ge\u00efsoleerde pieken: Enkele seconden met hoge <strong>wa<\/strong> normaal zijn, wijzen alleen hardnekkige plateaus op een structureel knelpunt. <strong>%utiel<\/strong> dicht bij 100% is alleen kritisch als <strong>wacht op<\/strong> gaat op hetzelfde moment omhoog - anders is het apparaat gewoon bezet. Op <strong>SSD<\/strong>\/NVMe is een hogere <strong>avgqu-sz<\/strong> vaak opzettelijk om gebruik te maken van intern parallellisme; ik geef alleen gas als latentiedoelen worden gemist. Ik controleer CPU-frequentieschaling: Agressieve energiebesparing kan reactietijden verhogen en dus <strong>wa<\/strong> lijken te verergeren. En ik scheid applicatie TTFB van opslaglatentie - netwerk, TLS handshakes en upstream services kunnen vergelijkbare symptomen veroorzaken zonder <strong>iostat<\/strong> \u201eis \u201cschuldig\".<\/p>\n\n<h2>Korte samenvatting voor admins<\/h2>\n<p>De I\/O wachttijdanalyse met iostat en vmstat werkt snel als ik wa, await, %util en avgqu-sz samen lees en relateer aan de werklastcontext. Ik identificeer eerst of er echt sprake is van apparaatverzadiging of dat geheugen- en app-patronen de latentie bepalen en kies dan de juiste hefboom. Kleine, gerichte aanpassingen aan query's, terugschrijfparameters, schedulers of wachtrijdiepte hebben vaak het grootste effect voordat dure hardwareveranderingen nodig zijn. Meten, hypothese, veranderen en opnieuw meten blijven mijn vaste volgorde zodat beslissingen begrijpelijk en herhaalbaar blijven. Zo houd ik <strong>Linux<\/strong>-server reageert sneller en zorgt voor merkbaar betere <strong>Reactietijden<\/strong> onder belasting.<\/p>","protected":false},"excerpt":{"rendered":"<p>Server I\/O wachttijd analyse met iostat en vmstat: Optimaliseer linux server statistieken voor maximale prestaties in hosting.<\/p>","protected":false},"author":1,"featured_media":19327,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[780],"tags":[],"class_list":["post-19334","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":"74","_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":"I\/O Wait Analyse","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":"19327","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/19334","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=19334"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/19334\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/19327"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=19334"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=19334"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=19334"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}