{"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-wait-analyse-iostat-vmstat-metrics-disk","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/server-io-wait-analyse-iostat-vmstat-metrics-disk\/","title":{"rendered":"Analyse af server-I\/O-ventetid med iostat og vmstat: Optimering af Linux-servermetrikker"},"content":{"rendered":"<p>Jeg viser trin for trin, hvordan I\/O wait-analysen med iostat og vmstat g\u00f8r flaskehalse synlige, og hvilke Linux-servermetrikker der t\u00e6ller for hurtige svartider. P\u00e5 den m\u00e5de s\u00e6tter jeg klare t\u00e6rskler, fortolker typiske m\u00f8nstre og foresl\u00e5r konkrete foranstaltninger til at optimere <strong>I\/O<\/strong> og <strong>CPU<\/strong> i.<\/p>\n\n<h2>Centrale punkter<\/h2>\n<ul>\n  <li><strong>iostat<\/strong> og <strong>vmstat<\/strong> giver et komplement\u00e6rt billede af CPU- og lagerbelastning.<\/li>\n  <li><strong>wa<\/strong> via 15-20% og <strong>%utile<\/strong> via 80% viser en I\/O-flaskehals.<\/li>\n  <li><strong>afvente<\/strong> og <strong>avgqu-sz<\/strong> forklare latenstid og k\u00f8er.<\/li>\n  <li><strong>mpstat<\/strong> registrerer uj\u00e6vnt fordelt belastning p\u00e5 tv\u00e6rs af CPU-kerner.<\/li>\n  <li><strong>Indstilling<\/strong> sp\u00e6nder fra <strong>MySQL<\/strong> til kerneparametre og lagring.<\/li>\n<\/ul>\n\n<h2>Hvad betyder I\/O Wait p\u00e5 Linux-servere?<\/h2>\n<p>Under I\/O wait venter CPU'en i tomgang, fordi den venter p\u00e5 langsommere hukommelses- eller netv\u00e6rksenheder, hvilket er kendt som <strong>wa<\/strong>-v\u00e6rdi i v\u00e6rkt\u00f8jer som top eller vmstat. Jeg vurderer denne procentdel som den tid, hvor tr\u00e5de blokerer, og foresp\u00f8rgsler afsluttes senere, hvilket brugerne direkte f\u00f8ler som tr\u00e6ghed. V\u00e6rdier over 10-20% indikerer ofte en fuldt udnyttet <strong>Opbevaring<\/strong>Subsystem, f.eks. n\u00e5r harddiske, RAID-arrays eller NFS-mounts udnyttes fuldt ud. I hostingops\u00e6tninger med databaser giver uindekserede foresp\u00f8rgsler og skrivetoppe un\u00f8dvendige ventetider p\u00e5 <strong>Disk<\/strong>. Hvis du vil genopfriske begreberne, kan du finde det grundl\u00e6ggende p\u00e5 <a href=\"https:\/\/webhosting.de\/da\/io-wait-forsta-hukommelsesflaskehals-lose-optimering\/\">Forst\u00e5 I\/O-ventetid<\/a>, f\u00f8r jeg tager til tr\u00e6ning.<\/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>Hurtig start: l\u00e6s vmstat korrekt<\/h2>\n<p>Med vmstat kan jeg tjekke de vigtigste <strong>Linux<\/strong>-og genkende de f\u00f8rste m\u00f8nstre uden den store indsats. Kaldet vmstat 1 10 giver ti snapshots, hvor jeg er s\u00e6rligt opm\u00e6rksom p\u00e5 kolonnerne wa (I\/O wait), bi\/bo (block I\/O) og si\/so (swap). For mig indikerer h\u00f8je bo-v\u00e6rdier med samtidig stigende wa mange blokerende skriveadgange, hvilket ofte indikerer bufferbegr\u00e6nsninger eller langsomme medier. Hvis si\/so forbliver p\u00e5 nul, men wa stiger markant, er mistanken om ren <strong>Opbevaring<\/strong>-begr\u00e6nsning. P\u00e5 v\u00e6rter med flere kerner kombinerer jeg vmstat med mpstat -P ALL 1, fordi I\/O-ventetid ofte kun p\u00e5virker enkelte kerner og derfor ser mere harml\u00f8s ud i gennemsnit, end den faktisk er.<\/p>\n\n<h2>CPU fine image: us\/sy\/st, run queue og context switch<\/h2>\n<p>Med vmstat og mpstat l\u00e6ser jeg mere end bare <strong>wa<\/strong>: H\u00f8j <strong>os<\/strong>Det \"computertunge\" applikationsarbejde vises i de f\u00f8lgende afsnit, <strong>sy<\/strong> indikerer kernel\/driver-arbejde, for eksempel med intensivt <strong>I\/O<\/strong>. I virtualiserede milj\u00f8er er jeg opm\u00e6rksom p\u00e5 <strong>st<\/strong> (Stj\u00e6le): H\u00f8je st-v\u00e6rdier betyder, at VM'en mister CPU-tid, hvilket kunstigt \u00f8ger ventetiden med et identisk I\/O-m\u00f8nster. Jeg sammenligner ogs\u00e5 k\u00f8rek\u00f8en (<strong>r<\/strong> i vmstat) med antallet af CPU'er: Et permanent h\u00f8jere r end antallet af CPU'er indikerer overbelastning ved CPU'en, ikke ved <strong>Opbevaring<\/strong>. Mange kontekst\u00e6ndringer (<strong>cs<\/strong>) i kombination med sm\u00e5 synkrone skrivninger er en indikator for snakkesalige I\/O-m\u00f8nstre. P\u00e5 den m\u00e5de undg\u00e5r jeg at fejlfortolke CPU-knaphed som et I\/O-problem.<\/p>\n\n<h2>Forst\u00e5else af iostat i dybden: vigtige metrikker<\/h2>\n<p>iostat -x 1 giver mig extended <strong>Disk<\/strong>-m\u00e5linger, der tydeligt beskriver latenstid, udnyttelse og k\u00f8er. Jeg starter m\u00e5lingen for belastningstoppe og korrelerer %util, await, svctm og avgqu-sz for at skelne mellem \u00e5rsag og virkning. Hvis %util stiger til 90-100%, mens await og avgqu-sz ogs\u00e5 stiger, ser jeg en m\u00e6ttet <strong>Tallerken<\/strong> eller en begr\u00e6nset m\u00e6ngde. Hvis await viser h\u00f8je v\u00e6rdier med moderat %util, tjekker jeg for interferens fra caching, controllerbegr\u00e6nsninger eller enkelte store foresp\u00f8rgsler. r\/s og w\/s bringer frekvensen ind i billedet, mens MB_read og MB_wrtn forklarer volumen, hvilket giver mig vigtige sammenligningsv\u00e6rdier for dedikerede SSD- og NVMe-ops\u00e6tninger.<\/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 og RAID: hvad %util, await og k\u00f8-dybde betyder<\/h2>\n<p>Jeg skelner skarpt mellem medietyper: <strong>HDD<\/strong> vise h\u00f8jere <strong>afvente<\/strong>-v\u00e6rdier selv med et moderat signal, fordi hovedbev\u00e6gelser dominerer. <strong>SSD<\/strong>\/NVMe skalerer godt med parallelitet, hvilket er grunden til, at en h\u00f8jere <strong>avgqu-sz<\/strong> kan v\u00e6re normal, s\u00e5 l\u00e6nge <strong>afvente<\/strong> forbliver inden for gr\u00e6nserne. P\u00e5 NVMe med flere indsendelses-\/afslutningsk\u00f8er l\u00e6ser jeg %util mere forsigtigt: Individuelle enheder kan allerede v\u00e6re p\u00e5 gr\u00e6nsen ved 60-70%, hvis appen ikke genererer nok parallelitet eller k\u00f8ens dybde (<strong>nr_anmodninger<\/strong>, <strong>k\u00f8_dybde<\/strong>) er for lille. I <strong>RAID<\/strong> Jeg tjekker, om spredning af tilf\u00e6ldig I\/O st\u00f8der p\u00e5 stripe-st\u00f8rrelser, der er for sm\u00e5; s\u00e5 <strong>afvente<\/strong> og <strong>%utile<\/strong> uj\u00e6vnt p\u00e5 de enkelte diske. Jeg ser derfor p\u00e5 iostat pr. medlemsenhed, ikke kun p\u00e5 den sammensatte volumen, for at g\u00f8re hotspots synlige. For logstrukturerede lag (f.eks. copy-on-write) forventer jeg lidt h\u00f8jere latenstider for skrivninger, men kompenserer for dette med st\u00f8rre tilbageskrivningsvinduer eller batching p\u00e5 app-siden.<\/p>\n\n<h2>Diagnostisk arbejdsgang for lange ventetider<\/h2>\n<p>Jeg starter hver analyse parallelt med vmstat 1 og iostat -x 1, s\u00e5 jeg kan se CPU-tilstande og enhedsstatus synkront og tildele dem til tiden. Derefter bruger jeg mpstat -P ALL 1 til at kontrollere, om enkelte kerner k\u00f8rer us\u00e6dvanligt h\u00f8jt. <strong>wa<\/strong> hvilket forhindrer forkert fortolkede gennemsnitsv\u00e6rdier. Hvis der er tegn p\u00e5 en \u00e5rsag, bruger jeg pidstat -d eller iotop til at se pr\u00e6cis, hvilken PID der bruger flest I\/O-shares. I hostingmilj\u00f8er med databaser skelner jeg f\u00f8rst mellem l\u00e6setoppe og skrivetoppe, da write-back-strategier og fsync-m\u00f8nstre genererer meget forskellige symptomer og derfor kr\u00e6ver en m\u00e5lrettet indsats. <strong>Foranstaltninger<\/strong> g\u00f8r det muligt. For mere dybdeg\u00e5ende sp\u00f8rgsm\u00e5l om opbevaring kan en oversigt som den p\u00e5 <a href=\"https:\/\/webhosting.de\/da\/io-flaskehals-hosting-latency-analyse-optimering-storage\/\">I\/O-flaskehals i hosting<\/a>, f\u00f8r jeg \u00e6ndrer p\u00e5 kernen eller filsystemet.<\/p>\n\n<h2>Klar afgr\u00e6nsning mellem virtualisering og containere<\/h2>\n<p>I VM'er overvejer jeg <strong>wa<\/strong> sammen med <strong>st<\/strong> (Steal) og desuden m\u00e5le p\u00e5 hypervisoren, fordi det kun er der, de rigtige enheder og <strong>Stikord<\/strong> er synlige. Storage-aggregeringer (thin provisioning, dedupe, snapshots) flytter latenstidstoppe ned i stakken - i VM'en har dette f\u00f8lgende effekt <strong>afvente<\/strong> springer, mens %util forbliver ubem\u00e6rket. I containere begr\u00e6nser eller afkobler jeg <strong>I\/O<\/strong> med Cgroup-regler (f.eks. IOPS\/throughput-gr\u00e6nser) for at kunne <strong>St\u00f8jende naboer<\/strong> for at t\u00e6mme dem. Jeg dokumenterer gr\u00e6nserne for hver tjeneste, s\u00e5 de m\u00e5lte v\u00e6rdier kan reproduceres, og alarmerne bevarer deres kontekst. Vigtigt: En h\u00f8j <strong>wa<\/strong> i VM'en kan udl\u00f8ses af backups, scrubs eller rebuilds i hele v\u00e6rten - jeg korrelerer tidspunkter med v\u00e6rtsjobs, f\u00f8r jeg r\u00f8rer ved appen.<\/p>\n\n<h2>Gr\u00e6nser, t\u00e6rskler og n\u00e6ste skridt<\/h2>\n<p>Jeg bruger et par klare t\u00e6rskler til at afg\u00f8re, om der er en reel flaskehals, og hvad der skal g\u00f8res for at stabilisere ydelsen m\u00e6rkbart. Jeg tager hensyn til medietype, arbejdsbyrde og latenstidskrav, fordi de samme tal p\u00e5 HDD og NVMe har forskellige konsekvenser. Jeg bruger f\u00f8lgende tabel som en hurtig guide, som jeg bruger i mine playbooks. Jeg m\u00e5ler flere gange i l\u00f8bet af minutter og under belastning, s\u00e5 afvigelser ikke skaber falske alarmer, og jeg kan genkende tendenser. Jeg bruger dette som grundlag for m\u00e5lrettet handling i stedet for refleksivt at udskifte hardware eller <strong>Parametre<\/strong> massivt.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Metrikker<\/th>\n      <th>T\u00e6rskel<\/th>\n      <th>fortolkning<\/th>\n      <th>N\u00e6ste skridt<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>wa<\/strong> (vmstat)<\/td>\n      <td>&gt; 15-20%<\/td>\n      <td>Betydelig I\/O-ventetid<\/td>\n      <td>Tjek iostat; find \u00e5rsagen med pidstat\/iotop; analyser caching og skrivninger<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>%utile<\/strong> (iostat)<\/td>\n      <td>&gt; 80-90%<\/td>\n      <td>Anvendt enhed<\/td>\n      <td>korrel\u00e9r await\/avgqu-sz; tjek k\u00f8-dybde, scheduler, RAID og SSD\/NVMe<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>afvente<\/strong> (ms)<\/td>\n      <td>&gt; 10-20 ms SSD, &gt; 30-50 ms HDD<\/td>\n      <td>\u00d8get ventetid<\/td>\n      <td>Skelne mellem tilf\u00e6ldig og sekventiel; tilpasse filsystemindstillinger, tilbageskrivning, journalisering<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>avgqu-sz<\/strong><\/td>\n      <td>&gt; 1-2 vedvarende<\/td>\n      <td>K\u00f8en vokser<\/td>\n      <td>Begr\u00e6ns\/for\u00f8g paralleliteten; optimer appens I\/O-m\u00f8nster; tjek controllerens gr\u00e6nser<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>si\/so<\/strong> (vmstat)<\/td>\n      <td>&gt; 0 under belastning<\/td>\n      <td>Flaskehals for opbevaring<\/td>\n      <td>\u00d8g RAM; tuning af foresp\u00f8rgsler\/cache; tjek swappiness\/hukommelsesgr\u00e6nser<\/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>\u00c5rsager i stakken: DB, filsystem, virtualisering<\/h2>\n<p>Med databaser ser jeg ofte uindekserede joins, buffere, der er for sm\u00e5, og overdrevne fsync-kald som den faktiske <strong>\u00c5rsager<\/strong> for h\u00f8je ventev\u00e6rdier. Jeg tjekker foresp\u00f8rgselsplaner, aktiverer logfiler for langsomme udsagn og justerer st\u00f8rrelser som InnoDB buffer pool, logfilst\u00f8rrelser og \u00e5bne filer objektivt. P\u00e5 filsystemniveau ser jeg p\u00e5 monteringsmuligheder, journaltilstande og tilpasning til RAID-stripen, fordi de forkerte kombinationer f\u00e5r ventetiderne til at eksplodere. I virtualiserede ops\u00e6tninger stoler jeg ikke p\u00e5 m\u00e5linger i VM'en alene, men kigger p\u00e5 v\u00e6rten, da det er her, de rigtige block-enheder og <strong>Stikord<\/strong> bliver synlige. Det giver mig mulighed for klart at adskille effekten af deduplikering, tynd provisionering eller n\u00e6rliggende VM'er fra applikationsm\u00f8nstrene.<\/p>\n\n<h2>Filsystem og mount-muligheder i detaljer<\/h2>\n<p>Jeg evaluerer filsystemer i lyset af arbejdsbyrden: <strong>ext4<\/strong> i ordnet eller tilbageskrevet tilstand minimerer barrierer for skriveintensitet, mens <strong>XFS<\/strong> scorer med sit logdesign til parallelle arbejdsbelastninger. Indstillinger som f.eks. <strong>Ingen tid<\/strong> eller <strong>relatime<\/strong> reducere metadataskrivninger, <strong>dovenskab<\/strong> flytter opdateringer af tidsstempler til tilbageskrivning i bundter. For journaling tjekker jeg commit-intervallerne (f.eks. commit=) og tjekker, om force flushes (barrierer) forv\u00e6rres af controllerens cache-politikker. P\u00e5 RAID er jeg opm\u00e6rksom p\u00e5 ren tilpasning til stripen (Parted\/FDISK med 1MiB start), ellers <strong>afvente<\/strong> gennem Read-Modify-Write, selv med angiveligt sekventielle m\u00f8nstre. Til databaser bruger jeg ofte O_DIRECT eller direkte log flush-strategier - men kun efter m\u00e5ling, fordi filsystemets cache kan reducere l\u00e6sebelastningen dramatisk, hvis arbejdss\u00e6ttet passer ind i den.<\/p>\n\n<h2>Tuning: fra kernen til appen<\/h2>\n<p>Jeg starter med enkle gevinster, f.eks. indeksering af foresp\u00f8rgsler, batchskrivning og fornuftig konfiguration af connection pooling, f\u00f8r jeg g\u00e5r i gang p\u00e5 systemniveau. For writeback justerer jeg vm.dirty_background_ratio, vm.dirty_ratio og vm.dirty_expire_centisecs p\u00e5 en kontrolleret m\u00e5de, s\u00e5 systemet skriver sammenh\u00e6ngende og genererer mindre blokering uden at tilstoppe hukommelsen. For blokenheder tjekker jeg I\/O-planl\u00e6gningen, k\u00f8-dybden og read-ahead, fordi disse parametre direkte former latenstid og genneml\u00f8b. P\u00e5 RAID-controllere indstiller jeg stripe-st\u00f8rrelse og cache-politik, mens jeg p\u00e5 <strong>SSD<\/strong>\/NVMe for firmware, TRIM og konsekvente indstillinger for overprovisionering. Efter hver \u00e6ndring kontrollerer jeg med vmstat og iostat over flere minutter, om ventetiden falder, og %util forbliver stabil, f\u00f8r jeg tager det n\u00e6ste skridt.<\/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>Afbrydelser, NUMA og affiniteter<\/h2>\n<p>Jeg overv\u00e5ger IRQ-belastning og NUMA-topologi, fordi begge dele har en m\u00e6rkbar effekt p\u00e5 ventetiden. <strong>NVMe<\/strong>Jeg binder afbrydelser til CPU'erne i controllerens NUMA-dom\u00e6ne via affinitet, s\u00e5 datastierne forbliver korte. Hvis IRQ-stormen k\u00f8rer p\u00e5 en kerne, ser jeg h\u00f8je <strong>sy<\/strong> og resten af CPU'erne ser ud til at v\u00e6re inaktive; <strong>mpstat<\/strong> afsl\u00f8rer dette. Jeg tillader kun irqbalance, hvis distributionen matcher hardwaren - ellers s\u00e6tter jeg specifikke affiniteter. Jeg tjekker ogs\u00e5, om applikationen og dens <strong>I\/O<\/strong> arbejde i den samme NUMA-zone (lagerplacering), fordi adgang p\u00e5 tv\u00e6rs af sokler for\u00e5rsager ventetider i <strong>afvente<\/strong> kan maskeres.<\/p>\n\n<h2>Automatiser og visualiser m\u00e5linger<\/h2>\n<p>For at v\u00e6re sikker p\u00e5, at jeg genkender tendenser, automatiserer jeg m\u00e5linger og integrerer iostat\/vmstat i overv\u00e5gningsv\u00e6rkt\u00f8jer, som kan vise historiske data. <strong>Data<\/strong> gemme. Jeg indstiller alarmerne konservativt, for eksempel fra wa &gt; 15% over flere intervaller, kombineret med t\u00e6rskler for await og %util for at undg\u00e5 falske alarmer. Til de overordnede metrikker bruger jeg dashboards, der sammenstiller CPU-, storage-, netv\u00e6rks- og app-metrikker, s\u00e5 sammenh\u00e6ngen bliver synlig med det samme. Hvis du har brug for en introduktion til metrikker, kan du finde dem p\u00e5 <a href=\"https:\/\/webhosting.de\/da\/server-metrics-cpu-idle-load-wait-analyse-serverboost\/\">Server-m\u00e5linger<\/a> kompakt kontekst for det daglige arbejde. Det, der er vigtigt for mig, er en gentagelig proces: m\u00e5l, opstil en hypotese, udf\u00f8r justeringen, m\u00e5l igen, og f\u00e6rdigg\u00f8r resultaterne. <strong>Resultater<\/strong> dokument.<\/p>\n\n<h2>Reproducerbare belastningstests med fio<\/h2>\n<p>Hvis jeg mangler en reel belastning eller \u00f8nsker at verificere hypoteser, bruger jeg kortvarige <strong>fio<\/strong>-tests. Jeg simulerer repr\u00e6sentative m\u00f8nstre (f.eks. 4k tilf\u00e6ldig l\u00e6sning, 64k sekventiel skrivning, blandede 70\/30-profiler) og varierer <strong>iodepth<\/strong>, for at indstille sweet spot-vinduet mellem <strong>afvente<\/strong> og gennemstr\u00f8mning. Jeg holder teststier strengt adskilt fra produktionsdata og noterer mig gr\u00e6nsebetingelser (filsystem, monteringsmuligheder, planl\u00e6gning, k\u00f8-dybde), s\u00e5 jeg kan kategorisere resultaterne korrekt. Efter tuning bruges de samme tests som regressionstjek; kun n\u00e5r <strong>afvente<\/strong> og <strong>%utile<\/strong> konsekvent ser bedre ud, foretager jeg \u00e6ndringer p\u00e5 overfladen.<\/p>\n\n<h2>Genkendelse af fejlm\u00f8nstre: typiske m\u00f8nstre<\/h2>\n<p>Hvis jeg observerer h\u00f8j wa med samtidig h\u00f8j %utile og stigende avgqu-sz, taler alt for m\u00e6tning p\u00e5 <strong>Enhed<\/strong>, dvs. reelle fysiske gr\u00e6nser. H\u00f8je await-v\u00e6rdier med moderat %util tyder p\u00e5 s\u00e6rlige forhold ved controlleren eller cachen, f.eks. barrierer, write-through eller sporadiske flushes. Stigende si\/so-v\u00e6rdier sammen med dyk i cachen indikerer klart en mangel p\u00e5 RAM, som kunstigt puster I\/O op og \u00f8ger ventetiden. Hvis disken ikke er i\u00f8jnefaldende, men appen laver store, synkroniseringstunge skrivninger, flytter jeg arbejdet til asynkron skrivning, pipelining eller <strong>Batch<\/strong>-mekanismer. I NFS- eller netv\u00e6rkslagerops\u00e6tninger tjekker jeg ogs\u00e5 latenstid, MTU, retransmissioner og caching p\u00e5 serversiden, fordi netv\u00e6rkstiden her er direkte maskeret som I\/O-latenstid.<\/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 og distribueret storage<\/h2>\n<p>Med <strong>NFS<\/strong> og iSCSI skelner jeg mellem enhed og netv\u00e6rkssti: <strong>iostat<\/strong> viser kun, hvad bloklaget ser - jeg genkender ogs\u00e5 retransmissioner, ventetider og vinduesproblemer via netv\u00e6rksmetrikker. H\u00f8j <strong>afvente<\/strong> med moderat <strong>%utile<\/strong> p\u00e5 den virtuelle blokenhed er typisk, n\u00e5r netv\u00e6rket g\u00e5r i st\u00e5, eller cachen p\u00e5 serversiden k\u00f8ler ned. For NFS tjekker jeg mount-indstillinger (rsize\/wsize, proto, sync\/async) og serversiden (tr\u00e5de, eksportpolitikker, cache), for iSCSI sessions- og k\u00f8parametre. Jeg planl\u00e6gger vedligeholdelsesvinduer for serverjobs (scrubs, rebuilds, rebalancing), s\u00e5 de ikke m\u00e6tter det delte lager i spidsbelastningsperioder og dermed f\u00e5r serveren til at blive utilg\u00e6ngelig. <strong>wa<\/strong> p\u00e5 alle klienter.<\/p>\n\n<h2>Praktiske eksempler: tre korte scenarier<\/h2>\n<h3>Blogklynge med skrivetips<\/h3>\n<p>I prime time \u00f8ges kommentarer og cache invalidate, hvorefter await og avgqu-sz i iostat \u00f8ges markant, mens %util holder sig til 95%. Jeg \u00f8ger forsigtigt writeback-parametrene, optimerer cache invalidation p\u00e5 sti-niveau og \u00f8ger InnoDB-logbufferen, s\u00e5 der er f\u00e6rre sm\u00e5 sync-writes. Derefter falder await m\u00e5lbart, bo-v\u00e6rdierne forbliver h\u00f8je, men wa falder, hvilket straks reducerer svartiderne. Samtidig udskifter jeg enkelte HDD'er med SSD'er til journalen, hvilket yderligere afhj\u00e6lper flaskehalsen. M\u00f8nsteret viser, hvordan <strong>Batch<\/strong>-Kombin\u00e9r skrivning og hurtigere journalisering.<\/p>\n<h3>Shop med l\u00e6setoppe og s\u00f8geindeks<\/h3>\n<p>Kampagner genererer tung l\u00e6sebelastning, r\/s skyder i vejret, await forbliver moderat, men appen reagerer stadig tr\u00e6gt p\u00e5 filternavigation. Jeg genkender mange unbuffered foresp\u00f8rgsler uden passende indekser, der overskrider filsystemets cache-arbejdss\u00e6t. Med m\u00e5lrettet indeksering og omskrivning af foresp\u00f8rgsler falder r\/s, hits er oftere i cachen, og iostat bekr\u00e6fter lavere MB_read med samme throughput. Samtidig \u00f8ger jeg read-ahead en smule for at betjene sekventielle scanninger mere effektivt, hvilket reducerer latenstiden yderligere. S\u00e5dan kontrollerer jeg, at <strong>L\u00e6s<\/strong>-m\u00f8nstre f\u00f8rer til cache-hits igen.<\/p>\n<h3>VM-v\u00e6rt med \u201est\u00f8jende nabo\u201c<\/h3>\n<p>I individuelle VM'er viser top h\u00f8j wa, men iostat i VM'en ser kun virtuelle enheder med misvisende udnyttelse. Jeg m\u00e5ler ogs\u00e5 p\u00e5 hypervisoren, ser m\u00e6ttede reelle block-enheder og identificerer en n\u00e6rliggende VM med aggressive backups som \u00e5rsagen. B\u00e5ndbreddebegr\u00e6nsninger og \u00e6ndrede backup-vinduer stabiliserer await og %util i hele v\u00e6rten. Derefter m\u00e5ler jeg igen i VM'en og p\u00e5 v\u00e6rten for at bekr\u00e6fte og forhindre effekten p\u00e5 begge sider. Dette bekr\u00e6fter, at \u00e6gte <strong>Enheder<\/strong>-m\u00e5linger viser altid sandheden hos v\u00e6rten.<\/p>\n\n<h2>Tjekliste til n\u00e6ste h\u00e6ndelse<\/h2>\n<p>Jeg starter logfiler og m\u00e5linger f\u00f8rst, s\u00e5 ingen signaler g\u00e5r tabt, og lader vmstat 1 og iostat -x 1 k\u00f8re i flere minutter. Derefter tidskorrelerer jeg peaks med app-begivenheder og systemtimere, f\u00f8r jeg indkredser individuelle processer med pidstat -d og formulerer hypoteser. Det n\u00e6ste skridt er at tjekke hukommelse, swap og cache-hits, s\u00e5 RAM-mangel ikke fejlagtigt opfattes som <strong>Disk<\/strong>-problemet dukker op. F\u00f8rst n\u00e5r jeg har isoleret \u00e5rsagen, \u00e6ndrer jeg pr\u00e6cis \u00e9n ting, logger indstillingen og evaluerer effekten p\u00e5 await, %util og wa. P\u00e5 den m\u00e5de holder jeg analysen reproducerbar, l\u00e6rer af hver eneste h\u00e6ndelse og reducerer tiden, indtil problemet er l\u00f8st. <strong>L\u00f8sning<\/strong> helt klart.<\/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>Hyppige fejlfortolkninger og snublesten<\/h2>\n<p>Jeg lader mig ikke narre af isolerede toppe: Enkelte sekunder med h\u00f8j <strong>wa<\/strong> er normale, kun vedvarende plateauer indikerer en strukturel flaskehals. <strong>%utile<\/strong> t\u00e6t p\u00e5 100% er kun kritisk, hvis <strong>afvente<\/strong> g\u00e5r op p\u00e5 samme tid - ellers er apparatet simpelthen optaget. P\u00e5 <strong>SSD<\/strong>\/NVMe er en h\u00f8jere <strong>avgqu-sz<\/strong> ofte med vilje for at udnytte den interne parallelitet; jeg drosler kun ned, n\u00e5r latency-m\u00e5lene ikke n\u00e5s. Jeg tjekker CPU-frekvensskaleringen: Aggressiv str\u00f8mbesparelse kan \u00f8ge svartiderne og dermed <strong>wa<\/strong> synes at blive v\u00e6rre. Og jeg adskiller applikations-TTFB fra lagringsforsinkelse - netv\u00e6rk, TLS-h\u00e5ndtryk og upstream-tjenester kan give lignende symptomer uden <strong>iostat<\/strong> \u201eer \u201cskyldig\".<\/p>\n\n<h2>Kort resum\u00e9 til administratorer<\/h2>\n<p>I\/O-venteanalysen med iostat og vmstat fungerer hurtigt, hvis jeg l\u00e6ser wa, await, %util og avgqu-sz sammen og relaterer dem til arbejdsbelastningskonteksten. Jeg identificerer f\u00f8rst, om der er tale om reel enhedsm\u00e6tning, eller om det er hukommelses- og app-m\u00f8nstre, der driver ventetiden, og v\u00e6lger derefter den rette l\u00f8ftestang. Sm\u00e5, m\u00e5lrettede justeringer af foresp\u00f8rgsler, writeback-parametre, schedulere eller k\u00f8-dybde har ofte den st\u00f8rste effekt, f\u00f8r det er n\u00f8dvendigt med dyre hardware\u00e6ndringer. M\u00e5ling, hypotese, \u00e6ndring og genm\u00e5ling er min faste r\u00e6kkef\u00f8lge, s\u00e5 beslutningerne forbliver forst\u00e5elige og gentagelige. Det er s\u00e5dan, jeg holder <strong>Linux<\/strong>-serveren er responsiv og sikrer m\u00e6rkbart bedre <strong>Svartider<\/strong> under belastning.<\/p>","protected":false},"excerpt":{"rendered":"<p>Analyse af server-I\/O-ventetid med iostat og vmstat: Optimer linux-serverens metrikker for maksimal ydelse i 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":"61","_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\/da\/wp-json\/wp\/v2\/posts\/19334","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/comments?post=19334"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/19334\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/19327"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=19334"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=19334"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=19334"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}