{"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-vaenta-analysera-iostat-vmstat-metrics-disk","status":"publish","type":"post","link":"https:\/\/webhosting.de\/sv\/server-io-wait-analyse-iostat-vmstat-metrics-disk\/","title":{"rendered":"Analys av server-I\/O-v\u00e4ntan med iostat och vmstat: Optimera m\u00e4tv\u00e4rden f\u00f6r Linux-server"},"content":{"rendered":"<p>Jag visar steg f\u00f6r steg hur I\/O wait-analysen med iostat och vmstat synligg\u00f6r flaskhalsar och vilka Linux-serverm\u00e5tt som \u00e4r viktiga f\u00f6r snabba svarstider. P\u00e5 s\u00e5 s\u00e4tt s\u00e4tter jag tydliga tr\u00f6skelv\u00e4rden, tolkar typiska m\u00f6nster och f\u00f6resl\u00e5r konkreta \u00e5tg\u00e4rder f\u00f6r att optimera <strong>I\/O<\/strong> och <strong>CPU<\/strong> i.<\/p>\n\n<h2>Centrala punkter<\/h2>\n<ul>\n  <li><strong>iostat<\/strong> och <strong>vmstat<\/strong> ger en kompletterande bild av CPU- och lagringsbelastningen.<\/li>\n  <li><strong>wa<\/strong> via 15-20% och <strong>%utile<\/strong> via 80% visar en I\/O-flaskhals.<\/li>\n  <li><strong>inv\u00e4nta<\/strong> och <strong>avgqu-sz<\/strong> f\u00f6rklara latenstid och k\u00f6er.<\/li>\n  <li><strong>mpstat<\/strong> uppt\u00e4cker oj\u00e4mnt f\u00f6rdelad belastning mellan CPU-k\u00e4rnorna.<\/li>\n  <li><strong>Tuning<\/strong> varierar fr\u00e5n <strong>MySQL<\/strong> till k\u00e4rnparametrar och lagring.<\/li>\n<\/ul>\n\n<h2>Vad betyder I\/O Wait p\u00e5 Linux-servrar?<\/h2>\n<p>Under I\/O wait v\u00e4ntar CPU:n i on\u00f6dan eftersom den v\u00e4ntar p\u00e5 l\u00e5ngsammare minnes- eller n\u00e4tverksenheter, vilket kan ses som <strong>wa<\/strong>-v\u00e4rde i verktyg som top eller vmstat. Jag utv\u00e4rderar denna procentandel som den tid d\u00e5 tr\u00e5dar blockeras och f\u00f6rfr\u00e5gningar slutf\u00f6rs senare, vilket anv\u00e4ndarna direkt k\u00e4nner som tr\u00f6ghet. V\u00e4rden \u00f6ver 10-20% indikerar ofta en fullt utnyttjad <strong>F\u00f6rvaring<\/strong>-delsystem, t.ex. n\u00e4r h\u00e5rddiskar, RAID-arrayer eller NFS-mounts utnyttjas till full kapacitet. I hostingkonfigurationer med databaser leder oindexerade f\u00f6rfr\u00e5gningar och skrivtoppar till on\u00f6diga v\u00e4ntetider p\u00e5 <strong>Disk<\/strong>. Om du vill fr\u00e4scha upp begreppen kan du hitta grunderna p\u00e5 <a href=\"https:\/\/webhosting.de\/sv\/io-wait-foersta-minnesflaskhals-atgaerda-optimering\/\">F\u00f6rst\u00e5 I\/O-v\u00e4ntan<\/a>, innan jag g\u00e5r till praktiken.<\/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>Snabbstart: l\u00e4s vmstat korrekt<\/h2>\n<p>Med vmstat kan jag kontrollera de viktigaste <strong>Linux<\/strong>-och k\u00e4nna igen initiala m\u00f6nster utan st\u00f6rre anstr\u00e4ngning. Anropet vmstat 1 10 ger tio \u00f6gonblicksbilder d\u00e4r jag \u00e4gnar s\u00e4rskild uppm\u00e4rksamhet \u00e5t kolumnerna wa (I\/O wait), bi\/bo (block I\/O) och si\/so (swap). F\u00f6r mig tyder h\u00f6ga bo-v\u00e4rden med samtidigt \u00f6kande wa p\u00e5 m\u00e5nga blockerande skriv\u00e5tkomster, vilket ofta indikerar buffertgr\u00e4nser eller l\u00e5ngsamma media. Om si\/so ligger kvar p\u00e5 noll, men wa stiger markant, \u00e4r misstanken om ren <strong>F\u00f6rvaring<\/strong>-begr\u00e4nsning. I v\u00e4rddatorer med flera k\u00e4rnor kombinerar jag vmstat med mpstat -P ALL 1, eftersom I\/O-v\u00e4ntan ofta bara p\u00e5verkar enskilda k\u00e4rnor och d\u00e4rf\u00f6r verkar mer harml\u00f6s i genomsnitt \u00e4n vad den faktiskt \u00e4r.<\/p>\n\n<h2>CPU-finbild: us\/sy\/st, k\u00f6rk\u00f6 och kontextv\u00e4xling<\/h2>\n<p>Med vmstat och mpstat l\u00e4ser jag mer \u00e4n bara <strong>wa<\/strong>: H\u00f6g <strong>oss<\/strong>Det \"datatunga\" applikationsarbetet visas i f\u00f6ljande avsnitt, <strong>sy<\/strong> indikerar kernel\/driver-arbete, till exempel med intensiv <strong>I\/O<\/strong>. I virtualiserade milj\u00f6er \u00e4r jag uppm\u00e4rksam p\u00e5 <strong>st<\/strong> (St\u00f6ld): H\u00f6ga st-v\u00e4rden inneb\u00e4r att den virtuella datorn f\u00f6rlorar CPU-tid, vilket artificiellt bl\u00e5ser upp latenserna med ett identiskt I\/O-m\u00f6nster. Jag j\u00e4mf\u00f6r ocks\u00e5 k\u00f6rk\u00f6n (<strong>r<\/strong> i vmstat) med antalet CPU:er: Ett permanent h\u00f6gre r \u00e4n antalet CPU:er indikerar \u00f6verbelastning vid CPU:n, inte vid <strong>F\u00f6rvaring<\/strong>. M\u00e5nga f\u00f6r\u00e4ndringar i sammanhanget (<strong>cs<\/strong>) i kombination med sm\u00e5 synkrona skrivningar \u00e4r en indikator p\u00e5 chattande I\/O-m\u00f6nster. P\u00e5 s\u00e5 s\u00e4tt undviker jag att misstolka CPU-brist som ett I\/O-problem.<\/p>\n\n<h2>F\u00f6rst\u00e5 iostat p\u00e5 djupet: viktiga m\u00e4tv\u00e4rden<\/h2>\n<p>iostat -x 1 ger mig ut\u00f6kad <strong>Disk<\/strong>-m\u00e4tv\u00e4rden som tydligt beskriver latens, utnyttjande och k\u00f6er. Jag startar m\u00e4tningen vid belastningstoppar och korrelerar %util, await, svctm och avgqu-sz f\u00f6r att skilja p\u00e5 orsak och verkan. Om %util stiger till 90-100%, samtidigt som await och avgqu-sz ocks\u00e5 stiger, ser jag en m\u00e4ttad <strong>Platta<\/strong> eller en begr\u00e4nsad volym. Om await visar h\u00f6ga v\u00e4rden med m\u00e5ttlig %util kontrollerar jag om det finns st\u00f6rningar fr\u00e5n cachelagring, styrenhetsbegr\u00e4nsningar eller enskilda stora f\u00f6rfr\u00e5gningar. r\/s och w\/s ger frekvensen en bild, medan MB_read och MB_wrtn f\u00f6rklarar volymen, vilket ger mig viktiga j\u00e4mf\u00f6relsev\u00e4rden f\u00f6r dedikerade SSD- och NVMe-installationer.<\/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 och RAID: vad %util, await och k\u00f6djup betyder<\/h2>\n<p>Jag g\u00f6r en strikt \u00e5tskillnad mellan olika typer av medier: <strong>H\u00c5RDDISK<\/strong> visa h\u00f6gre <strong>inv\u00e4nta<\/strong>-v\u00e4rden \u00e4ven med en m\u00e5ttlig ledtr\u00e5d, eftersom huvudr\u00f6relserna dominerar. <strong>SSD<\/strong>\/NVMe skalar bra med parallellitet, vilket \u00e4r anledningen till att en h\u00f6gre <strong>avgqu-sz<\/strong> kan vara normal s\u00e5 l\u00e4nge som <strong>inv\u00e4nta<\/strong> f\u00f6rblir inom gr\u00e4nserna. P\u00e5 NVMe med flera k\u00f6er f\u00f6r inl\u00e4mning\/avslut l\u00e4ser jag %util mer f\u00f6rsiktigt: enskilda enheter kan redan vara p\u00e5 gr\u00e4nsen vid 60-70% om appen inte genererar tillr\u00e4ckligt med parallellitet eller om k\u00f6djupet (<strong>nr_f\u00f6rfr\u00e5gningar<\/strong>, <strong>k\u00f6_djup<\/strong>) \u00e4r f\u00f6r liten. I <strong>RAID<\/strong> Jag kontrollerar om spridningen av slumpm\u00e4ssig I\/O ger stripe-storlekar som \u00e4r f\u00f6r sm\u00e5; d\u00e5 <strong>inv\u00e4nta<\/strong> och <strong>%utile<\/strong> oj\u00e4mnt p\u00e5 medlemsskivorna. Jag tittar d\u00e4rf\u00f6r p\u00e5 iostat per medlemsenhet, inte bara p\u00e5 den sammansatta volymen, f\u00f6r att synligg\u00f6ra hotspots. F\u00f6r loggstrukturerade lager (t.ex. copy-on-write) f\u00f6rv\u00e4ntar jag mig n\u00e5got h\u00f6gre latenser f\u00f6r skrivningar, men kompenserar f\u00f6r detta med f\u00f6rstorade \u00e5terskrivningsf\u00f6nster eller batchning p\u00e5 app-sidan.<\/p>\n\n<h2>Diagnostiskt arbetsfl\u00f6de f\u00f6r l\u00e5nga v\u00e4ntetider<\/h2>\n<p>Jag startar varje analys parallellt med vmstat 1 och iostat -x 1 s\u00e5 att jag kan se CPU-tillst\u00e5nd och enhetsstatus synkront och tilldela dem till en tidsperiod. Jag anv\u00e4nder sedan mpstat -P ALL 1 f\u00f6r att kontrollera om enskilda k\u00e4rnor k\u00f6rs ovanligt h\u00f6gt. <strong>wa<\/strong> vilket f\u00f6rhindrar felaktigt tolkade medelv\u00e4rden. Om det finns indikationer p\u00e5 en orsak anv\u00e4nder jag pidstat -d eller iotop f\u00f6r att se exakt vilken PID som anv\u00e4nder flest I\/O-andelar. I hostingmilj\u00f6er med databaser skiljer jag f\u00f6rst mellan l\u00e4s- och skrivtoppar, eftersom write-back-strategier och fsync-m\u00f6nster genererar mycket olika symptom och d\u00e4rf\u00f6r kan anv\u00e4ndas f\u00f6r riktade <strong>\u00c5tg\u00e4rder<\/strong> g\u00f6r det m\u00f6jligt. F\u00f6r mer djupg\u00e5ende fr\u00e5gor om lagring kan en \u00f6versikt som den p\u00e5 <a href=\"https:\/\/webhosting.de\/sv\/io-flaskhals-hosting-latency-analys-optimering-lagring\/\">I\/O-flaskhals i hosting<\/a>, innan jag \u00e4ndrar i k\u00e4rnan eller filsystemet.<\/p>\n\n<h2>Tydlig gr\u00e4nsdragning mellan virtualisering och containrar<\/h2>\n<p>I VM-apparater anser jag <strong>wa<\/strong> tillsammans med <strong>st<\/strong> (Steal) och dessutom m\u00e4ta p\u00e5 hypervisorn, eftersom det bara \u00e4r d\u00e4r de verkliga enheterna och <strong>Ledtr\u00e5dar<\/strong> \u00e4r synliga. Lagringsaggregeringar (tunn provisionering, dedupe, snapshots) flyttar latens-toppar ned\u00e5t i stacken - i VM:n har detta f\u00f6ljande effekt <strong>inv\u00e4nta<\/strong> hoppar, medan %util f\u00f6rblir oansenlig. I beh\u00e5llare begr\u00e4nsar eller frikopplar jag <strong>I\/O<\/strong> med Cgroup-regler (t.ex. IOPS\/genomstr\u00f6mningsgr\u00e4nser) f\u00f6r att kunna <strong>Noisy Neighbors<\/strong> f\u00f6r att t\u00e4mja dem. Jag dokumenterar gr\u00e4nsv\u00e4rdena per tj\u00e4nst s\u00e5 att m\u00e4tv\u00e4rdena \u00e4r reproducerbara och larmen beh\u00e5ller sitt sammanhang. Viktigt: En h\u00f6g <strong>wa<\/strong> i den virtuella datorn kan utl\u00f6sas av s\u00e4kerhetskopior, rensningar eller ombyggnader i hela v\u00e4rden - jag korrelerar tider med v\u00e4rdjobb innan jag r\u00f6r appen.<\/p>\n\n<h2>Gr\u00e4nser, tr\u00f6skelv\u00e4rden och n\u00e4sta steg<\/h2>\n<p>Jag anv\u00e4nder n\u00e5gra tydliga tr\u00f6skelv\u00e4rden f\u00f6r att avg\u00f6ra om det finns en verklig flaskhals och vilka \u00e5tg\u00e4rder som ska vidtas f\u00f6r att m\u00e4rkbart stabilisera prestandan. Jag tar h\u00e4nsyn till typen av media, arbetsbelastning och latensbehov, eftersom samma siffror f\u00f6r HDD och NVMe f\u00e5r olika konsekvenser. Jag anv\u00e4nder f\u00f6ljande tabell som en snabbguide som jag anv\u00e4nder i mina playbooks. Jag m\u00e4ter flera g\u00e5nger under minuter och under belastning s\u00e5 att avvikande v\u00e4rden inte genererar falsklarm och jag kan k\u00e4nna igen trender. Jag anv\u00e4nder detta som grund f\u00f6r riktade \u00e5tg\u00e4rder ist\u00e4llet f\u00f6r att reflexm\u00e4ssigt byta ut h\u00e5rdvara eller <strong>Parametrar<\/strong> massivt.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>M\u00e4tetal<\/th>\n      <th>Tr\u00f6skelv\u00e4rde<\/th>\n      <th>tolkning<\/th>\n      <th>N\u00e4sta steg<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>wa<\/strong> (vmstat)<\/td>\n      <td>&gt; 15-20%<\/td>\n      <td>Betydande I\/O-v\u00e4ntetid<\/td>\n      <td>Kontrollera iostat; hitta orsaken med pidstat\/iotop; analysera cachelagring och skrivningar<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>%utile<\/strong> (iostat)<\/td>\n      <td>&gt; 80-90%<\/td>\n      <td>Enhet som anv\u00e4nds<\/td>\n      <td>korrelera await\/avgqu-sz; kontrollera k\u00f6djup, schemal\u00e4ggare, RAID och SSD\/NVMe<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>inv\u00e4nta<\/strong> (ms)<\/td>\n      <td>&gt; 10-20 ms SSD, &gt; 30-50 ms HDD<\/td>\n      <td>\u00d6kad latenstid<\/td>\n      <td>Skillnad mellan slumpm\u00e4ssig och sekventiell; anpassa filsystemalternativ, writeback, journaling<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>avgqu-sz<\/strong><\/td>\n      <td>&gt; 1-2 ih\u00e5llande<\/td>\n      <td>K\u00f6erna v\u00e4xer<\/td>\n      <td>Begr\u00e4nsa\/\u00f6ka parallellismen; optimera appens I\/O-m\u00f6nster; kontrollera styrenhetens gr\u00e4nser<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>si\/so<\/strong> (vmstat)<\/td>\n      <td>&gt; 0 under belastning<\/td>\n      <td>Flaskhals i lagringsutrymmet<\/td>\n      <td>\u00d6ka RAM-minnet; tuning av query\/cache; kontrollera swappiness\/minnesgr\u00e4nser<\/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>Orsaker i stacken: DB, filsystem, virtualisering<\/h2>\n<p>N\u00e4r det g\u00e4ller databaser ser jag ofta oindexerade joins, f\u00f6r sm\u00e5 buffertar och \u00f6verdrivna fsync-anrop n\u00e4r den faktiska <strong>Orsaker<\/strong> f\u00f6r h\u00f6ga v\u00e4ntev\u00e4rden. Jag kontrollerar fr\u00e5geplaner, aktiverar loggar f\u00f6r l\u00e5ngsamma uttalanden och justerar storlekar som InnoDB buffertpool, loggfilstorlekar och \u00f6ppna filer objektivt. P\u00e5 filsystemniv\u00e5 tittar jag p\u00e5 monteringsalternativ, journall\u00e4gen och anpassning till RAID-remsan, eftersom fel kombinationer f\u00e5r v\u00e4ntetiderna att explodera. I virtualiserade konfigurationer f\u00f6rlitar jag mig inte enbart p\u00e5 m\u00e4tningar i den virtuella datorn, utan tittar p\u00e5 v\u00e4rden, eftersom det \u00e4r d\u00e4r de verkliga blockenheterna och <strong>Ledtr\u00e5dar<\/strong> blir synliga. P\u00e5 s\u00e5 s\u00e4tt kan jag tydligt separera effekterna av deduplicering, tunn provisionering eller n\u00e4rliggande virtuella datorer fr\u00e5n applikationsm\u00f6nstren.<\/p>\n\n<h2>Filsystem och monteringsalternativ i detalj<\/h2>\n<p>Jag utv\u00e4rderar filsystem mot bakgrund av arbetsbelastningen: <strong>ext4<\/strong> i ordnat l\u00e4ge eller writeback-l\u00e4ge minimerar hindren f\u00f6r skrivintensitet, medan <strong>XFS<\/strong> po\u00e4ng med sin loggdesign f\u00f6r parallella arbetsbelastningar. Alternativ som t.ex. <strong>ingen tid<\/strong> eller . <strong>relatime<\/strong> minska skrivningar av metadata, <strong>lattid<\/strong> flyttar tidsst\u00e4mpeluppdateringar till \u00e5terskrivningen i buntar. F\u00f6r journaling kontrollerar jag commit-intervallerna (t.ex. commit=) och kontrollerar om forcerade rensningar (barri\u00e4rer) f\u00f6rv\u00e4rras av styrenhetens cachepolicy. P\u00e5 RAID \u00e4r jag uppm\u00e4rksam p\u00e5 ren anpassning till stripen (Parted\/FDISK med 1MiB start), annars <strong>inv\u00e4nta<\/strong> genom Read-Modify-Write \u00e4ven med f\u00f6rmodat sekventiella m\u00f6nster. F\u00f6r databaser anv\u00e4nder jag ofta O_DIRECT eller direkta loggspolningsstrategier - men f\u00f6rst efter m\u00e4tning, eftersom filsystemets cache kan minska l\u00e4sbelastningen dramatiskt om arbetsupps\u00e4ttningen passar in i den.<\/p>\n\n<h2>Tuning: fr\u00e5n k\u00e4rnan till appen<\/h2>\n<p>Jag b\u00f6rjar med enkla vinster, till exempel fr\u00e5geindexering, batchskrivning och f\u00f6rnuftig konfiguration av anslutningspoolning, innan jag b\u00f6rjar p\u00e5 systemniv\u00e5. F\u00f6r \u00e5terskrivning justerar jag vm.dirty_background_ratio, vm.dirty_ratio och vm.dirty_expire_centisecs p\u00e5 ett kontrollerat s\u00e4tt s\u00e5 att systemet skriver sammanh\u00e4ngande och genererar mindre blockering utan att blockera minnet. F\u00f6r blockenheter kontrollerar jag I\/O-schemal\u00e4ggaren, k\u00f6djupet och read-ahead eftersom dessa parametrar direkt p\u00e5verkar latens och genomstr\u00f6mning. P\u00e5 RAID-styrenheter st\u00e4ller jag in stripe-storlek och cache-policy, medan jag p\u00e5 <strong>SSD<\/strong>\/NVMe f\u00f6r firmware, TRIM och konsekventa inst\u00e4llningar f\u00f6r \u00f6verprovisionering. Efter varje \u00e4ndring verifierar jag med vmstat och iostat under flera minuter om v\u00e4ntetiden sjunker och %util f\u00f6rblir stabilt innan jag tar n\u00e4sta steg.<\/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>Avbrott, NUMA och affiniteter<\/h2>\n<p>Jag \u00f6vervakar IRQ-belastning och NUMA-topologi eftersom b\u00e5da har en m\u00e4rkbar effekt p\u00e5 f\u00f6rdr\u00f6jningarna. <strong>NVMe<\/strong>Jag binder avbrott till CPU:erna i styrenhetens NUMA-dom\u00e4n via affinitet s\u00e5 att datav\u00e4garna f\u00f6rblir korta. Om IRQ-stormen \u00e4r ig\u00e5ng p\u00e5 en k\u00e4rna ser jag h\u00f6ga <strong>sy<\/strong> och resten av CPU:erna verkar vara inaktiva; <strong>mpstat<\/strong> avsl\u00f6jar detta. Jag till\u00e5ter bara irq-balans om distributionen matchar h\u00e5rdvaran - annars st\u00e4ller jag in specifika affiniteter. Jag kontrollerar ocks\u00e5 om applikationen och dess <strong>I\/O<\/strong> arbeta i samma NUMA-zon (lagringsplats), eftersom \u00e5tkomst mellan olika socklar orsakar v\u00e4ntetider i <strong>inv\u00e4nta<\/strong> kan maskeras.<\/p>\n\n<h2>Automatisera och visualisera m\u00e4tning<\/h2>\n<p>F\u00f6r att vara s\u00e4ker p\u00e5 att jag k\u00e4nner igen trender automatiserar jag m\u00e4tningarna och integrerar iostat\/vmstat i \u00f6vervakningsverktyg som kan visa historiska data. <strong>Uppgifter<\/strong> spara. Jag st\u00e4ller in larm konservativt, till exempel fr\u00e5n wa &gt; 15% \u00f6ver flera intervall, kombinerat med tr\u00f6skelv\u00e4rden f\u00f6r await och %util f\u00f6r att undvika falsklarm. F\u00f6r \u00f6vergripande m\u00e4tv\u00e4rden anv\u00e4nder jag instrumentpaneler som sammanst\u00e4ller CPU-, lagrings-, n\u00e4tverks- och appm\u00e4tv\u00e4rden s\u00e5 att korrelationer blir omedelbart synliga. Om du beh\u00f6ver en introduktion till m\u00e4tv\u00e4rden kan du hitta dem p\u00e5 <a href=\"https:\/\/webhosting.de\/sv\/servermaetningar-cpu-tomgang-belastning-vaenta-analysera-serverboost\/\">M\u00e4tv\u00e4rden f\u00f6r server<\/a> kompakt sammanhang f\u00f6r det dagliga arbetet. Det \u00e4r viktigt f\u00f6r mig att ha en upprepningsbar process: m\u00e4t, formulera en hypotes, g\u00f6r en justering, m\u00e4t igen och analysera resultaten. <strong>Resultat<\/strong> dokument.<\/p>\n\n<h2>Reproducerbara belastningstester med fio<\/h2>\n<p>Om jag saknar en verklig belastning eller vill verifiera hypoteser anv\u00e4nder jag kortlivade <strong>fio<\/strong>-tester. Jag simulerar representativa m\u00f6nster (t.ex. 4k slumpm\u00e4ssig l\u00e4sning, 64k sekventiell skrivning, blandade 70\/30-profiler) och varierar <strong>iodepth<\/strong>, f\u00f6r att st\u00e4lla in sweet spot-f\u00f6nstret mellan <strong>inv\u00e4nta<\/strong> och genomstr\u00f6mning. Jag h\u00e5ller testv\u00e4garna strikt \u00e5tskilda fr\u00e5n produktionsdata och noterar gr\u00e4nsvillkoren (filsystem, monteringsalternativ, schemal\u00e4ggare, k\u00f6djup) s\u00e5 att jag kan kategorisera resultaten korrekt. Efter tuning anv\u00e4nds samma tester som en regressionskontroll; endast n\u00e4r <strong>inv\u00e4nta<\/strong> och <strong>%utile<\/strong> konsekvent ser b\u00e4ttre ut, jag g\u00f6r \u00e4ndringar p\u00e5 ytan.<\/p>\n\n<h2>Att k\u00e4nna igen felm\u00f6nster: typiska m\u00f6nster<\/h2>\n<p>Om jag observerar h\u00f6g wa med samtidigt h\u00f6g %utile och \u00f6kande avgqu-sz talar allt f\u00f6r en m\u00e4ttnad p\u00e5 <strong>Enhet<\/strong>, dvs. verkliga fysiska gr\u00e4nser. H\u00f6ga await-v\u00e4rden med m\u00e5ttliga %util-v\u00e4rden tyder p\u00e5 att styrenheten eller cacheminnet har speciella egenskaper, t.ex. barri\u00e4rer, genomskrivning eller sporadiska rensningar. Stigande si\/so-v\u00e4rden tillsammans med sjunkande cacheminne indikerar tydligt brist p\u00e5 RAM-minne, vilket artificiellt bl\u00e5ser upp I\/O och \u00f6kar v\u00e4ntetiderna. Om skivan f\u00f6rblir oansenlig, men appen skapar stora, synktunga skrivningar, flyttar jag arbetet till asynkron skrivning, pipelining eller <strong>Batch<\/strong>-mekanismer. I NFS- eller n\u00e4tverkslagringskonfigurationer kontrollerar jag \u00e4ven latens, MTU, retransmissioner och cachelagring p\u00e5 serversidan, eftersom n\u00e4tverkstiden h\u00e4r direkt maskeras som I\/O-latens.<\/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 och distribuerad lagring<\/h2>\n<p>Med <strong>NFS<\/strong> och iSCSI skiljer jag mellan enhet och n\u00e4tverksv\u00e4g: <strong>iostat<\/strong> visar bara vad blocklagret ser - jag k\u00e4nner ocks\u00e5 igen retransmissioner, latenser och f\u00f6nsterproblem via n\u00e4tverksm\u00e4tningar. H\u00f6g <strong>inv\u00e4nta<\/strong> med m\u00e5ttlig <strong>%utile<\/strong> p\u00e5 den virtuella blockenheten \u00e4r typiskt n\u00e4r n\u00e4tverket stannar eller cacheminnet p\u00e5 serversidan svalnar. F\u00f6r NFS kontrollerar jag monteringsalternativ (rsize\/wsize, proto, sync\/async) och serversidan (tr\u00e5dar, exportpolicyer, cache), f\u00f6r iSCSI sessions- och k\u00f6parametrarna. Jag planerar underh\u00e5llsf\u00f6nster f\u00f6r serverjobb (scrubs, rebuilds, rebalancing) s\u00e5 att de inte m\u00e4ttar den delade lagringen vid toppar och d\u00e4rmed g\u00f6r att servern blir otillg\u00e4nglig. <strong>wa<\/strong> p\u00e5 alla klienter.<\/p>\n\n<h2>Praktiska exempel: tre korta scenarier<\/h2>\n<h3>Bloggkluster med skrivtips<\/h3>\n<p>Vid prime time \u00f6kar kommentarer och cache invalidate, varp\u00e5 await och avgqu-sz i iostat \u00f6kar markant, medan %util h\u00e5ller sig till 95%. Jag \u00f6kar f\u00f6rsiktigt writeback-parametrarna, optimerar cache-invalidation p\u00e5 s\u00f6kv\u00e4gsniv\u00e5 och \u00f6kar InnoDB-loggbufferten s\u00e5 att det blir f\u00e4rre sm\u00e5 synkroniserade skrivningar. Efter det sjunker await m\u00e4tbart, bo-v\u00e4rdena f\u00f6rblir h\u00f6ga, men wa sjunker, vilket omedelbart minskar svarstiderna. Samtidigt ers\u00e4tter jag enskilda h\u00e5rddiskar med SSD-enheter f\u00f6r journalen, vilket ytterligare avlastar flaskhalsen. M\u00f6nstret visar hur <strong>Batch<\/strong>-Kombinera skrivande och snabbare journalf\u00f6ring.<\/p>\n<h3>Handla med l\u00e4stoppar och s\u00f6kindex<\/h3>\n<p>Kampanjer genererar tung l\u00e4sbelastning, r\/s skjuter i h\u00f6jden, v\u00e4ntan f\u00f6rblir m\u00e5ttlig, men appen reagerar fortfarande tr\u00f6gt p\u00e5 filternavigering. Jag k\u00e4nner igen m\u00e5nga obuffrade fr\u00e5gor utan l\u00e4mpliga index som \u00f6verstiger arbetsupps\u00e4ttningen f\u00f6r filsystemets cache. Med riktad indexering och omskrivning av fr\u00e5gor sjunker r\/s, tr\u00e4ffarna finns oftare i cacheminnet och iostat bekr\u00e4ftar l\u00e4gre MB_read med samma genomstr\u00f6mning. Samtidigt \u00f6kar jag read-ahead n\u00e5got f\u00f6r att serva sekventiella skanningar mer effektivt, vilket ytterligare minskar latenserna. S\u00e5 h\u00e4r kontrollerar jag att <strong>L\u00e4s<\/strong>-m\u00f6nster leder till cache-tr\u00e4ffar igen.<\/p>\n<h3>VM-v\u00e4rd med \u201ebullrig granne\u201c<\/h3>\n<p>I enskilda VM:er visar top h\u00f6g wa, men iostat i VM:n ser bara virtuella enheter med missvisande utnyttjande. Jag m\u00e4ter ocks\u00e5 p\u00e5 hypervisorn, ser m\u00e4ttade verkliga blockenheter och identifierar en angr\u00e4nsande VM med aggressiva s\u00e4kerhetskopior som orsaken. Bandbreddsbegr\u00e4nsningar och modifierade f\u00f6nster f\u00f6r s\u00e4kerhetskopiering stabiliserar await och %util i hela v\u00e4rden. Jag m\u00e4ter sedan igen i den virtuella datorn och p\u00e5 v\u00e4rden f\u00f6r att bekr\u00e4fta och f\u00f6rhindra effekten p\u00e5 b\u00e5da sidor. Detta bekr\u00e4ftar att verkliga <strong>Apparater<\/strong>-m\u00e4tningar visar alltid sanningen hos v\u00e4rden.<\/p>\n\n<h2>Checklista f\u00f6r n\u00e4sta incident<\/h2>\n<p>Jag startar loggar och m\u00e4tningar f\u00f6rst s\u00e5 att inga signaler g\u00e5r f\u00f6rlorade, och h\u00e5ller vmstat 1 och iostat -x 1 ig\u00e5ng i flera minuter. Sedan tidskorrelerar jag toppar med apph\u00e4ndelser och systemtimers innan jag letar upp enskilda processer med pidstat -d och formulerar hypoteser. I n\u00e4sta steg kontrolleras minnes-, swap- och cachetr\u00e4ffar s\u00e5 att RAM-brist inte felaktigt uppfattas som <strong>Disk<\/strong>-problemet dyker upp. F\u00f6rst n\u00e4r jag har isolerat orsaken \u00e4ndrar jag exakt en sak, loggar inst\u00e4llningen och utv\u00e4rderar effekten p\u00e5 await, %util och wa. P\u00e5 s\u00e5 s\u00e4tt h\u00e5ller jag analysen reproducerbar, l\u00e4r mig av varje incident och minskar tiden till <strong>L\u00f6sning<\/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>Frekventa feltolkningar och st\u00f6testenar<\/h2>\n<p>Jag l\u00e5ter mig inte luras av isolerade toppar: Enstaka sekunder med h\u00f6g <strong>wa<\/strong> \u00e4r normala, endast ih\u00e5llande plat\u00e5er tyder p\u00e5 en strukturell flaskhals. <strong>%utile<\/strong> n\u00e4ra 100% \u00e4r endast kritisk om <strong>inv\u00e4nta<\/strong> g\u00e5r upp samtidigt - annars \u00e4r enheten helt enkelt upptagen. P\u00e5 <strong>SSD<\/strong>\/NVMe \u00e4r en h\u00f6gre <strong>avgqu-sz<\/strong> ofta avsiktligt f\u00f6r att utnyttja intern parallellism; jag stryper bara n\u00e4r latensm\u00e5len missas. Jag kontrollerar CPU-frekvensskalning: Aggressiv str\u00f6msparande kan \u00f6ka svarstiderna och s\u00e5 vidare. <strong>wa<\/strong> verkar f\u00f6rv\u00e4rras. Och jag skiljer applikation TTFB fr\u00e5n lagringsf\u00f6rdr\u00f6jning - n\u00e4tverk, TLS-handskakningar och uppstr\u00f6ms tj\u00e4nster kan ge liknande symtom utan <strong>iostat<\/strong> \u201e\u00e4r \u201cskyldig\".<\/p>\n\n<h2>Kort sammanfattning f\u00f6r administrat\u00f6rer<\/h2>\n<p>Analysen av I\/O-v\u00e4ntan med iostat och vmstat fungerar snabbt om jag l\u00e4ser wa, await, %util och avgqu-sz tillsammans och relaterar dem till arbetsbelastningskontexten. Jag identifierar f\u00f6rst om det finns en verklig enhetsm\u00e4ttnad eller om det \u00e4r minnes- och appm\u00f6nster som driver latensen och v\u00e4ljer sedan l\u00e4mplig h\u00e4vst\u00e5ng. Sm\u00e5, riktade justeringar av fr\u00e5gor, \u00e5terskrivningsparametrar, schemal\u00e4ggare eller k\u00f6djup har ofta st\u00f6rst effekt innan dyra h\u00e5rdvaru\u00e4ndringar \u00e4r n\u00f6dv\u00e4ndiga. M\u00e4tning, hypotes, f\u00f6r\u00e4ndring och ny m\u00e4tning \u00e4r min fasta sekvens s\u00e5 att besluten f\u00f6rblir begripliga och repeterbara. Det \u00e4r s\u00e5 h\u00e4r jag beh\u00e5ller <strong>Linux<\/strong>-servern \u00e4r responsiv och s\u00e4kerst\u00e4ller m\u00e4rkbart b\u00e4ttre <strong>Svarstider<\/strong> under belastning.<\/p>","protected":false},"excerpt":{"rendered":"<p>Server I\/O wait analysis with iostat and vmstat: Optimera linuxserverns m\u00e4tv\u00e4rden f\u00f6r maximal prestanda 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":"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\/sv\/wp-json\/wp\/v2\/posts\/19334","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/comments?post=19334"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts\/19334\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media\/19327"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media?parent=19334"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/categories?post=19334"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/tags?post=19334"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}