{"id":21483,"date":"2026-09-17T11:51:02","date_gmt":"2026-09-17T09:51:02","guid":{"rendered":"https:\/\/webhosting.de\/linux-vmstat-richtig-interpretieren-performanceanalyse-monitoring\/"},"modified":"2026-09-17T11:51:02","modified_gmt":"2026-09-17T09:51:02","slug":"korrekt-fortolkning-af-linux-vmstat-ydeevneanalyse-og-overvagning","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/linux-vmstat-richtig-interpretieren-performanceanalyse-monitoring\/","title":{"rendered":"S\u00e5dan fortolkes vmstat i Linux korrekt for en effektiv ydeevneanalyse"},"content":{"rendered":"<p>Jeg viser dig, hvordan du l\u00e6ser vmstat i Linux m\u00e5lrettet: Du kan p\u00e5 f\u00e5 sekunder identificere CPU-flaskehalse, belastning p\u00e5 hukommelsen, swap og I\/O-ventetider. S\u00e5dan fortolker du kolonnerne r, b, free, si\/so, bi\/bo og us\/sy\/id\/wa\/st p\u00e5 en sikker m\u00e5de og udleder konkrete tiltag ud fra m\u00f8nstrene \u2013 uden at g\u00e6tte, med <strong>klar<\/strong> Regler.<\/p>\n\n<h2>Centrale punkter<\/h2>\n\n<ul>\n  <li><strong>K\u00f8<\/strong> vs. blokeringer: r viser CPU-belastning, b advarer om I\/O-ventetider.<\/li>\n  <li><strong>Hukommelse<\/strong> Vurder det realistisk: \u00bbgratis\u00ab i sig selv t\u00e6ller ikke; det afg\u00f8rende er, om det er s\u00e5dan eller ej.<\/li>\n  <li><strong>I\/O<\/strong> I fokus: bi\/bo er ukritiske, s\u00e5 l\u00e6nge wa forbliver lav.<\/li>\n  <li><strong>CPU-andele<\/strong> L\u00e6s: us+sy h\u00f8jt, id lavt \u2192 h\u00f8j udnyttelsesgrad.<\/li>\n  <li><strong>Basislinjer<\/strong> Udarbejde: Sammenligne v\u00e6rdier i hverdagen med problemfaser.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/linux-vmstat-analyse-9847.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hvad viser vmstat egentlig?<\/h2>\n\n<p>Vmstat samler processtatus, hukommelse, swap, blok-I\/O og CPU-andel i en kompakt udskrift, der p\u00e5 f\u00e5 sekunder giver et <strong>systemomfattende<\/strong> Giver et godt indtryk. F\u00f8rst l\u00e6ser jeg \u201eprocs\u201c for r\/b, derefter \u201ememory\/swap\u201c for free, buff, cache samt si\/so. S\u00e5 tjekker jeg \u201eio\u201c med bi\/bo og afslutter med \u201ecpu\u201c for us, sy, id, wa og eventuelt st. Denne r\u00e6kkef\u00f8lge hj\u00e6lper mig med at skelne mellem \u00e5rsag og virkning: et h\u00f8jt r-tal betyder regnebelastning, et h\u00f8jt b-tal peger p\u00e5 I\/O-ventetider, og et h\u00f8jt wa-tal forbinder CPU-inaktivitet med I\/O-latens. P\u00e5 den m\u00e5de kan jeg se, om det er regnearbejdet, hukommelsesmangel eller datamediet, der bremser systemet \u2013 og jeg sparer mig selv for <strong>Omveje<\/strong>.<\/p>\n\n<h2>Start om 60 sekunder: Opkald og intervaller<\/h2>\n\n<p>For at f\u00e5 et \u00f8jebliksbillede lige fra opstarten k\u00f8rer jeg \u201evmstat\u201c uden parametre; til l\u00f8bende analyser bruger jeg \u201evmstat 1\u201c eller \u201evmstat 5 12\u201c for tolv m\u00e5lepunkter hvert femte sekund og f\u00e5r en <strong>tidsm\u00e6ssig<\/strong> R\u00e6kke. Vigtigt: Den f\u00f8rste linje viser gennemsnitsv\u00e6rdier siden systemstart, s\u00e5 jeg l\u00e6gger is\u00e6r v\u00e6gt p\u00e5 de f\u00f8lgende linjer. Med Delay\/Count styrer jeg samplingsfrekvensen og varigheden, f.eks. \u201evmstat 1 30\u201c ved korte spidsbelastninger. Ved ustabile arbejdsbelastninger indstiller jeg 1\u20132 sekunder, ved rolige scenarier snarere 5 sekunder. Jeg observerer tendenser, ikke enkeltbilleder, fordi m\u00f8nstre afsl\u00f8rer de reelle <strong>\u00c5rsager<\/strong> vise.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/vmstat_performance_4567.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>At forst\u00e5 processer: r og b i hverdagen<\/h2>\n\n<p>Kolonnen r viser tr\u00e5de, der er klar til at k\u00f8re, men venter p\u00e5 CPU-tid, mens b t\u00e6ller blokerede tr\u00e5de, ofte i I\/O-ventetilstand. Hvis r ligger markant over antallet af fysiske kerner, tyder det p\u00e5, at <strong>CPU-flaskehals<\/strong> ; p\u00e5 fire kerner betragtes r=8 over l\u00e6ngere tid som et tydeligt signal. En b-v\u00e6rdi st\u00f8rre end 0 over l\u00e6ngere tid tyder p\u00e5 langsomme datamedier, overbelastede databaser eller langsomme netv\u00e6rks- eller lagringsstier. Jeg korrelerer r med us+sy og id: hvis id er lavt og r h\u00f8jt, k\u00e6mper CPU'en; hvis wa er h\u00f8jt og b h\u00f8jt, bremser I\/O. S\u00e5dan beslutter jeg, om jeg skal skalere regnekraft, optimere foresp\u00f8rgsler eller <strong>Opbevaringssystem<\/strong> Tjek.<\/p>\n\n<h2>Fortolkning af hukommelsesvariabler: free, buff, cache, swpd<\/h2>\n\n<p>En lav free-v\u00e6rdi er normalt under Linux, da kernen bruger RAM intensivt som cache, hvilket fremskynder filadgangen og giver reel <strong>Gennemstr\u00f8mning<\/strong> medf\u00f8rer. Derfor l\u00e6gger jeg mere v\u00e6gt p\u00e5 swpd og swap-str\u00f8mmene si\/so end p\u00e5 free alene. En h\u00f8j cache er god, s\u00e5 l\u00e6nge si\/so n\u00e6sten altid forbliver 0; f\u00f8rst vedvarende swap-aktivitet indikerer reelt pres. Hvis der desuden opst\u00e5r latenstid eller endda OOM, griber jeg ind: \u00f8ger RAM, trimmer processer i tide eller justerer cache- og JVM-st\u00f8rrelser. Konteksten er stadig vigtig: Arbejdsbelastning, hukommelsesst\u00f8rrelse og NUMA-layout bestemmer, hvad der i dit milj\u00f8 betragtes som <strong>sund<\/strong> g\u00e6lder.<\/p>\n\n<h2>Swap-aktivitet: klassificering p\u00e5 den ene eller den anden m\u00e5de<\/h2>\n\n<p>Kolonnerne \u00bbsi\u00ab og \u00bbso\u00ab m\u00e5ler den konstante datastr\u00f8m mellem RAM og swap i KB\/s og viser det reelle belastningsniveau p\u00e5 hukommelsen, ikke blot det, man oplever <strong>Mangel<\/strong>. Korte spidsbelastninger er normale, f.eks. n\u00e5r sider, der sj\u00e6ldent bruges, flyttes. Det bliver kritisk, hvis de p\u00e5 den ene eller anden m\u00e5de vedvarende forbliver st\u00f8rre end 0; det bremser det hele, da hver eneste udlagring medf\u00f8rer ekstra I\/O-omkostninger. H\u00f8je so-v\u00e6rdier tyder p\u00e5 aktiv udlagring, og responstiderne stiger markant. P\u00e5 dette tidspunkt stopper jeg \u00e5rsagerne: reducere hukommelsesforbruget, udvide RAM eller hukommelseskr\u00e6vende tjenester <strong>Melodi<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/vmstat-linux-performance-analysis-6234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Forst\u00e5else af blok-I\/O: bi og bo<\/h2>\n\n<p>Med bi\/bo kan jeg m\u00e5le l\u00e6se- og skrivehastigheden i blokke pr. sekund, men uden kontekst vurderer jeg den ikke; det afg\u00f8rende er samspillet med <strong>wa<\/strong>. H\u00f8je bi\/bo-v\u00e6rdier og samtidig en h\u00f8j wa-v\u00e6rdi viser, at lagringssystemet ikke kan f\u00f8lge med. Hvis jeg ser h\u00f8je bi-v\u00e6rdier i forbindelse med en database, tjekker jeg foresp\u00f8rgselsprofiler og cache-hits, f\u00f8r jeg udskifter hardware. For en mere detaljeret timing bruger jeg iostat og analyserer k\u00f8ens l\u00e6ngde og latenstider, s\u00e5 jeg <a href=\"https:\/\/webhosting.de\/da\/server-io-wait-analyse-iostat-vmstat-metrics-disk\/\">Analyse af I\/O-ventetid<\/a> og m\u00e5lrettet kan l\u00f8se flaskehalse. F\u00f8rst n\u00e5r wa forbliver lavt, men bi\/bo eksploderer vedvarende, overvejer jeg at <strong>Skalering<\/strong> af lagringssystemet.<\/p>\n\n<h2>CPU-andele: us, sy, id, wa, st<\/h2>\n\n<p>H\u00f8je US-v\u00e6rdier ved lav WA indikerer produktivt nyttearbejde, mens h\u00f8je SY-v\u00e6rdier tyder p\u00e5 en stor m\u00e6ngde kerneoverhead, f.eks. utallige sm\u00e5 I\/O-operationer eller mange <strong>\u00c6ndring af konteksten<\/strong>. Hvis id ligger t\u00e6t p\u00e5 0 og forbliver der, k\u00f8rer CPU\u2019en p\u00e5 gr\u00e6nsen; kombineret med et h\u00f8jt r-tal tyder det p\u00e5 en stor regnebelastning. Stiger wa, venter CPU\u2019en p\u00e5 I\/O \u2013 her giver finjustering af lagringssystemet ofte st\u00f8rre gevinst end CPU-opgraderinger. I VM\u2019er holder jeg \u00f8je med st (steal): H\u00f8je st-v\u00e6rdier afsl\u00f8rer, at hypervisoren afleder CPU-tid, s\u00e5 jeg tager en snak med operat\u00f8ren om v\u00e6rtsudnyttelsen. Jeg vurderer altid us+sy som en sum, da denne viser den aktive <strong>Arbejde<\/strong> i systemet.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/vmstat_linux_perf_Bild_7392.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hurtigvejledning: Kolonner og vejledende v\u00e6rdier<\/h2>\n\n<p>Jeg bruger nedenst\u00e5ende tabel som en kortfattet huskeliste, n\u00e5r jeg skal gennemg\u00e5 vmstat-udskrifter for en f\u00f8rste <strong>Vurdering<\/strong> tv\u00e6rl\u00e6sning.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Kolonne<\/th>\n      <th>Betydning<\/th>\n      <th>Hvad jeg l\u00e6gger m\u00e6rke til<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>r<\/td>\n      <td>Tr\u00e5de, der er klar til afspilning<\/td>\n      <td>Permanent &gt; Kerner \u2192 <strong>CPU-belastning<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>b<\/td>\n      <td>Blokerede tr\u00e5de<\/td>\n      <td>Konstant &gt; 0 + wa h\u00f8j \u2192 I\/O-problem<\/td>\n    <\/tr>\n    <tr>\n      <td>gratis<\/td>\n      <td>Gratis RAM<\/td>\n      <td>Et lavt tal er i orden, s\u00e5 l\u00e6nge si\/so forbliver \u2248 0<\/td>\n    <\/tr>\n    <tr>\n      <td>buff\/cache<\/td>\n      <td>FS-buffer\/sidebuffer<\/td>\n      <td>Meget cache er godt; kan godkendes <strong>blive<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>si\/so<\/td>\n      <td>Swap ind\/ud<\/td>\n      <td>Konstant &gt; 0 \u2192 faktisk lagertryk<\/td>\n    <\/tr>\n    <tr>\n      <td>bi\/bo<\/td>\n      <td>Blok-I\/O<\/td>\n      <td>Kun kritisk, hvis wa samtidig er h\u00f8j<\/td>\n    <\/tr>\n    <tr>\n      <td>us\/sy<\/td>\n      <td>Bruger\/Kerne<\/td>\n      <td>us+sy vedvarende &gt; 80% \u2192 h\u00f8j <strong>Belastning<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>id<\/td>\n      <td>tomgang<\/td>\n      <td>T\u00e6t p\u00e5 0 over tid \u2192 CPU overbelastet<\/td>\n    <\/tr>\n    <tr>\n      <td>wa<\/td>\n      <td>I\/O-ventetid<\/td>\n      <td>H\u00f8jt med b h\u00f8jt \u2192 Lagerplads som \u00e5rsag<\/td>\n    <\/tr>\n    <tr>\n      <td>st<\/td>\n      <td>Steal (VM'er)<\/td>\n      <td>H\u00f8j \u2192 Hypervisor tager <strong>CPU<\/strong>-tid<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Baselinjer og l\u00f8bende overv\u00e5gning<\/h2>\n\n<p>Jeg stoler ikke p\u00e5 enkeltst\u00e5ende \u00f8jebliksbilleder, men sammenligner v\u00e6rdierne med referencev\u00e6rdier fra rolige perioder, s\u00e5 jeg kan fjerne afvigelser p\u00e5 en pr\u00e6cis m\u00e5de <strong>genkende<\/strong>. \u201evmstat 1 60\u201c giver mig et belastningsprofil for et minut, som jeg sammenligner med kendte normale faser. For at f\u00e5 et historisk overblik bruger jeg <a href=\"https:\/\/webhosting.de\/da\/sar-sysstat-linux-serverovervagning\/\">sar\/sysstat-overv\u00e5gning<\/a>, for at vurdere tendenser over flere dage og sk\u00e6rpe gr\u00e6nsev\u00e6rdierne. Jeg indstiller alarmerne konservativt: r i forhold til kernerne, si\/so ulig 0 over flere intervaller, wa m\u00e6rkbart forh\u00f8jet. P\u00e5 den m\u00e5de reagerer jeg tidligt, inden brugerne rapporterer forsinkelser, og inden <strong>Toppen<\/strong>-faser eskalerer.<\/p>\n\n<h2>Vmstat i kombination med andre v\u00e6rkt\u00f8jer<\/h2>\n\n<p>Jeg starter med vmstat, tr\u00e6ffer en beslutning ud fra m\u00f8nstrene og g\u00e5r derefter m\u00e5lrettet i dybden med iostat, mpstat, pidstat eller applikationsmetrikker, s\u00e5 jeg kan finde \u00e5rsagerne <strong>klar<\/strong> tildele. Mens vmstat viser I\/O-ventetider, m\u00e5ler jeg med iostat latenstider og k\u00f8er for hvert enkelt enhed. Hvis r indikerer en kernebegr\u00e6nsning, viser mpstat kerneasymmetrier. Ved spidsbelastning i processerne leverer <a href=\"https:\/\/webhosting.de\/da\/pidstat-linux-procesanalyse-og-overvagning\/\">pidstat Procesanalyse<\/a> de mest heftige tr\u00e5de om tid. F\u00f8rst sammenh\u00e6ngen med logfiler og applikationstider g\u00f8r billedet klarere og f\u00f8rer mig til den egentlige <strong>\u00c5rsag<\/strong>.<\/p>\n\n<h2>Genkende m\u00f8nstre og handle<\/h2>\n\n<p>Hvis jeg ser, at r er h\u00f8j, id lav og wa moderat, optimerer applikationen ofte p\u00e5 en m\u00e5de, der kr\u00e6ver for meget regnekraft, og derfor tjekker jeg koden eller paralleliteten og planl\u00e6gger CPU-ressourcerne, f\u00f8r jeg <strong>Hardware<\/strong> kr\u00e6ver. Hvis b, wa og bi\/bo alle er h\u00f8je, overvejer jeg lagringsoptimering, foresp\u00f8rgselsoptimering og caching. Ved lav free med si\/so st\u00f8rre end 0 reducerer jeg lagerforbruget, streamer resultaterne eller \u00f8ger RAM. Hvis us er moderat og sy meget h\u00f8j, ser jeg p\u00e5 pakkefiltre, filsystemindstillinger eller drivere. Med denne tjekliste kan jeg handle hurtigt og bruge tiden der, hvor den g\u00f8r mest <strong>t\u00e6ller<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/vmstat-linux-analyst-7645.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>S\u00e5dan undg\u00e5r du m\u00e5lefejl: Pr\u00f8veudtagning, enheder, f\u00f8rste linje<\/h2>\n\n<p>Jeg v\u00e6lger bevidst ikke at bruge den f\u00f8rste linje til at identificere akutte fejl, da den har udf\u00f8rt gennemsnitsberegning siden opstart og udj\u00e6vner spidsbelastninger fuldst\u00e6ndigt. Desuden tilpasser jeg samplingsfrekvensen efter hypotesen om \u00e5rsagen: CPU-spidsbelastninger registrerer jeg med intervaller p\u00e5 1 sekund, langsomme hukommelsesl\u00e6kager med intervaller p\u00e5 5\u201310 sekunder. Jeg tager h\u00f8jde for enhederne: si\/so er KB\/s, bi\/bo er \u201eblokke\/s\u201c (historisk set 1 KB pr. blok, varierer afh\u00e6ngigt af vmstat-versionen). Jeg kontrollerer, om \u201evmstat -w\u201c (bred udskrift) undg\u00e5r afsk\u00e6ring af kolonner, og om \u00e6ndringer i clockfrekvensen (P-stater, Turbo) p\u00e5virker den kortsigtede opfattelse af belastningen. Jeg synkroniserer m\u00e5lingerne med applikationsspidser i stedet for blindt at se p\u00e5 \u201ehele minutter\u201c.<\/p>\n\n<h2>Afkodning af systemsektionen: in og cs<\/h2>\n\n<p>Ud over procs\/memory\/swap\/io\/cpu viser vmstat ogs\u00e5 \u201esystem\u201c: <strong>p\u00e5<\/strong> (afbrydelser\/sek.) og <strong>cs<\/strong> (Kontekstskift pr. sekund). Disse to v\u00e6rdier fort\u00e6ller mig meget om kernel-overhead.<\/p>\n<ul>\n  <li>cs er meget h\u00f8jt ved moderat arbejdsbelastning: tr\u00e5dfladder, for sm\u00e5 worker-batches eller lock-konflikter. Jeg \u00f8ger batchst\u00f8rrelserne, justerer paralleliteten (tr\u00e5dpuljer) og tjekker scheduler-\/mutex-hotspots.<\/li>\n  <li>i pludselige stigninger: netv\u00e6rks- eller lagringsinterrupt-storme, NAPI\/polling-effekter eller timer-interrupts. Jeg sammenligner med sy-andelen og iostat-resultaterne for at unders\u00f8ge drivere eller netv\u00e6rksstier.<\/li>\n  <li>cs er proportional med r: Det tyder p\u00e5 et konstant pres for at skifte kontekst p\u00e5 grund af overdreven parallelitet. Jeg begr\u00e6nser den aktive parallelitet eller binder hot-threads til kerner.<\/li>\n<\/ul>\n<p>Jeg sammenholder altid in\/cs med sy og b\/wa: F\u00f8rst n\u00e5r man ser det i sammenh\u00e6ng, fremkommer et klart billede af, om kernel-arbejdet er meningsfuldt (f.eks. gennemstr\u00f8mning) eller udg\u00f8r ren overhead.<\/p>\n\n<h2>Nyttige vmstat-varianter og indstillinger<\/h2>\n\n<p>Jeg bruger vmstat fleksibelt for at f\u00e5 yderligere perspektiver uden at skifte v\u00e6rkt\u00f8j:<\/p>\n<ul>\n  <li><strong>vmstat -s<\/strong>: Sumt\u00e6ller (f.eks. processer, der er startet siden opstart, major\/minor page faults). Ideel til at sammenligne l\u00e6kager eller antal tilf\u00e6lde over bestemte tidsintervaller.<\/li>\n  <li><strong>vmstat -m<\/strong>: Slab-anvendelse \u2013 hj\u00e6lper med at klassificere kernel-cacher (Dentry\/Inode, netv\u00e6rk) som RAM-forbrugere.<\/li>\n  <li><strong>vmstat -d<\/strong>: Diskh\u00e6ndelser p\u00e5 samlet niveau. Er ikke en erstatning for iostat, men god til en hurtig realitetstjek.<\/li>\n  <li><strong>vmstat -S M<\/strong>: Skift enheder (M\/K) for at g\u00f8re tallene lettere at l\u00e6se.<\/li>\n  <li><strong>vmstat -w<\/strong>: Bredere kolonner forhindrer, at store talr\u00e6kker bliver afsk\u00e5ret.<\/li>\n<\/ul>\n<p>Jeg kombinerer disse varianter med korte intervaller, s\u00e5 jeg ikke g\u00e5r glip af begivenheder og alligevel bevarer overblikket.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/vmstat_linux_analyse_3947.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Containere, VM'er og cgroups: S\u00e6rlige forhold<\/h2>\n\n<p>I containere fortolker jeg vmstat med forsigtighed: Mange kerneoplysninger g\u00e6lder for hele v\u00e6rten, mens begr\u00e6nsningerne stammer fra Cgroups. H\u00f8je r-v\u00e6rdier i en container afspejler navnerummets perspektiv, men den reelle CPU-tid kan v\u00e6re begr\u00e6nset af CPU-kvoter eller CPU-andele. Jeg henviser til <strong>st<\/strong> (Steal) i VM\u2019er: En h\u00f8j st-v\u00e6rdi betyder, at hypervisoren tager tid fra mig \u2013 s\u00e5 hj\u00e6lper selv perfekt app-optimering ikke meget, s\u00e5 l\u00e6nge v\u00e6rten er overbelastet. Ved hukommelsesbegr\u00e6nsninger i Cgroups kan si\/so udblive, selvom containeren \u201espj\u00e6tter\u201c ved gr\u00e6nsen (OOM-kills i stedet for swap). Derfor tjekker jeg desuden OOM-logfiler og Cgroup-statistikker og sammenligner vmstat-billeder med gr\u00e6nserne.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/vmstat-linux-analyst-7645.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NUMA og affinitet: N\u00e5r lokalitet er afg\u00f8rende<\/h2>\n\n<p>P\u00e5 NUMA-v\u00e6rter tjekker jeg r og us\/sy pr. kerne (med mpstat) og holder \u00f8je med, om enkelte sockets \u201ek\u00f8rer varmt\u201c, mens andre st\u00e5r i tomgang. Uhensigtsm\u00e6ssig hukommelseslokalisering f\u00f8rer til flere stigninger i cs\/sy og b\/wa p\u00e5 grund af fjerne hukommelsesadgange. Jeg tester CPU- og hukommelsesaffinitet (cpuset, numactl), indstiller store heaps til \u201einterleaved\u201c eller \u00bbstrictly local\u00ab og s\u00f8rger for, at hot-threads k\u00f8rer der, hvor deres data-footprint befinder sig. Et stabilt NUMA-layout udj\u00e6vner cs, reducerer wa-udfald og \u00f8ger <strong>Planl\u00e6gbarhed<\/strong> under belastning.<\/p>\n\n<h2>Undg\u00e5 misforst\u00e5elser: wa og b er mere end blot \u201elangsomme datamedier\u201c<\/h2>\n\n<p>wa stiger ikke kun ved klassiske diskforsinkelser: Ogs\u00e5 NFS\/netv\u00e6rk med h\u00f8j forsinkelse, m\u00e6ttet objektlagring, blokerende cloud-volumener eller langsomme page-cache-writebacks presser wa op. b t\u00e6ller opgaver i uafbrydelig dvaletilstand (D-state) \u2013 herunder ogs\u00e5 fastl\u00e5sninger i drivere, netv\u00e6rksstier eller filsysteml\u00e5se. Derfor vurderer jeg aldrig wa\/b isoleret, men altid sammen med bi\/bo og applikationstiminger. Hvis wa er h\u00f8jt, men bi\/bo er lavt, er der ofte tale om en <strong>Afh\u00e6ngighed af ventetid<\/strong> ud over det rent tekniske sp\u00f8rgsm\u00e5l om enhedens gennemstr\u00f8mning (f.eks. locking, remote I\/O, writeback-k\u00f8).<\/p>\n\n<h2>Tuning med sans for proportioner: Swappiness, Writeback, Scheduler<\/h2>\n\n<p>Jeg \u00e6ndrer f\u00f8rst Kernel-Tuner efter at have foretaget m\u00e5linger og med en plan for tilbagef\u00f8rsel:<\/p>\n<ul>\n  <li><strong>vm.swappiness<\/strong>: En lav v\u00e6rdi d\u00e6mper proaktivt swapping, hvilket er godt for applikationer, hvor latenstiden er afg\u00f8rende \u2013 en for lav v\u00e6rdi kan \u00f8ge presset p\u00e5 sidecachen.<\/li>\n  <li><strong>vm.dirty_background_ratio \/ vm.dirty_ratio<\/strong> (eller *_bytes): P\u00e5virker tidspunktet for writeback. For h\u00f8je v\u00e6rdier medf\u00f8rer lange skrivebursts (wa-spidser), mens for lave v\u00e6rdier \u00f8ger antallet af sm\u00e5, konstante flushes (sy\/bo stiger).<\/li>\n  <li><strong>I\/O-scheduler\/k\u00f8dybde<\/strong>: Andre Optima-indstillinger p\u00e5 NVMe end p\u00e5 HDD\/RAID. Jeg m\u00e5ler afvejningerne mellem latenstid og gennemstr\u00f8mning med iostat, f\u00f8r jeg foretager \u00e6ndringer.<\/li>\n  <li><strong>Netv\u00e6rksstier<\/strong>: Der str\u00f8mmer mange sm\u00e5 pakker\/interrupts ind i \/cs\/sy. De vigtigste indstillingsmuligheder er GRO\/LRO, RPS\/RFS og IRQ-affinitet \u2013 jeg m\u00e5ler f\u00f8r og efter.<\/li>\n<\/ul>\n<p>Mit m\u00e5l er stabile, forudsigelige kurver i vmstat: us\/sy skal v\u00e6re mere j\u00e6vne, wa\/b lavere, si\/so t\u00e6t p\u00e5 0. F\u00f8rst da opgraderer jeg hardwaren.<\/p>\n\n<h2>Playbook: 3-minutters analyse med vmstat<\/h2>\n\n<ul>\n  <li>0:00\u20130:30 \u2013 \u201evmstat 1 30\u201c: Ignorer den f\u00f8rste linje, og gennemg\u00e5 derefter r\/b, us\/sy\/id\/wa. Sp\u00f8rgsm\u00e5l: CPU-begr\u00e6nsning (r h\u00f8j, id lav) eller I\/O-begr\u00e6nsning (b\/wa h\u00f8j)?<\/li>\n  <li>0:30\u20131:00 \u2013 Visning af akkumulator: Kontroller swpd og si\/so. Er si\/so konstant &gt; 0? \u2192 \u00e6gte akkumulatortryk. free er underordnet.<\/li>\n  <li>1:00\u20131:30 \u2013 I\/O-kontekst: bi\/bo vs. wa. H\u00f8je bi\/bo-v\u00e6rdier uden wa? \u2192 I\/O kobles fra. H\u00f8je wa-v\u00e6rdier ved moderate bi\/bo-v\u00e6rdier? \u2192 Latens\/lock\/remote-I\/O.<\/li>\n  <li>1:30\u20132:00 \u2013 system-sektion: in\/cs i forhold til sy. Er cs meget h\u00f8jt? \u2192 Unders\u00f8g trykket fra kontekstskift, parallelitet\/l\u00e5sning.<\/li>\n  <li>2:00\u20133:00 \u2013 Fastl\u00e6gge hypotesen og v\u00e6lge det rette v\u00e6rkt\u00f8j: iostat til I\/O-indeks, mpstat til kerneasymmetrier, pidstat til proces-hotspots. F\u00f8rst derefter tuning\/skalering.<\/li>\n<\/ul>\n\n<h2>Udvidede eksempler fra praksis<\/h2>\n\n<ul>\n  <li><strong>CPU-m\u00e6tning uden h\u00f8j r<\/strong>: us+sy ved 90%+, id \u2248 0, men r er moderat \u2192 single-thread-hotspot eller affinitetsproblem. L\u00f8sning: Paralleliser hot-path, kontroller core-pinning.<\/li>\n  <li><strong>Swap-Thrash<\/strong>: uanset hvad er v\u00e6rdien tydeligt &gt; 0, b\/wa stiger, us falder \u2192 RAM er alt for lille, eller heap er forkert dimensioneret. Foranstaltninger: \u00d8g RAM, reducer arbejdsm\u00e6ngden, juster swappiness.<\/li>\n  <li><strong>Kernel-overhead<\/strong>: sy h\u00f8j, cs\/in h\u00f8j, us moderat \u2192 mange sm\u00e5 systemkald\/I\/O. L\u00f8sning: Batch-behandling, reduktion af systemkald, tjek af filsystemets mount-indstillinger.<\/li>\n  <li><strong>Tilbagef\u00f8rselsophobning<\/strong>: wa h\u00f8j, bo h\u00f8j, korte b\u00f8lger \u2192 dirty-gr\u00e6nser for h\u00f8je, lagringslatens varierer. Gennemg\u00e5 writeback-tuning og I\/O-scheduler.<\/li>\n  <li><strong>Presset for virtualisering<\/strong>: st synlig, r svinger, id \u201espringer\u201c \u2192 V\u00e6rten deler CPU. L\u00f8sning: Kontroller vCPU-tildeling\/placering, reducer overcommit.<\/li>\n<\/ul>\n\n<h2>Kend vmstats begr\u00e6nsninger<\/h2>\n\n<p>Vmstat er et fremragende <strong>Tidlig varslingssensor<\/strong>, men ikke et mikroskop. Det viser mig, at der er et problem, og hvor det ligger \u2013 ikke den enkelte skyldige fil, foresp\u00f8rgselen eller tr\u00e5den. Derfor g\u00e5r jeg efter vmstat-diagnosen konsekvent i gang med avancerede v\u00e6rkt\u00f8jer, bekr\u00e6fter hypoteser fra flere vinkler og \u00e6ndrer derefter kun \u00e9n ting ad gangen. P\u00e5 den m\u00e5de forbliver forbedringerne m\u00e5lbare og reproducerbare.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/vmstat_linux_analyse_3947.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Opsummering fra praksis<\/h2>\n\n<p>Med vmstat kan jeg p\u00e5 f\u00e5 sekunder se, om det er CPU, RAM, swap eller I\/O, der bremser, ved at se p\u00e5 r, b, si\/so, bi\/bo og us\/sy\/id\/wa\/st i samspil <strong>l\u00e6se<\/strong>. Jeg vurderer tendenser frem for enkeltv\u00e6rdier, sammenligner med referencev\u00e6rdier og inddrager om n\u00f8dvendigt iostat, mpstat, pidstat samt historiske m\u00e5linger. Den f\u00f8rste linje ignorerer jeg i tilf\u00e6lde af akutte forstyrrelser og koncentrerer mig om de efterf\u00f8lgende linjer med fast samplingsfrekvens. Jeg tr\u00e6ffer datadrevne beslutninger: r i forhold til kerner, si\/so vedvarende forskellig fra 0, wa vedvarende forh\u00f8jet, us+sy t\u00e6t p\u00e5 fuld udnyttelse. P\u00e5 den m\u00e5de udleder jeg hurtigt konkrete foranstaltninger og holder systemerne m\u00e6rkbart <strong>reaktiv<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>L\u00e6r, hvordan du korrekt kan fortolke Linux vmstat for at identificere flaskehalse i CPU, hukommelse og I\/O og optimere din ydeevneanalyse med s\u00f8geordet vmstat linux.<\/p>","protected":false},"author":1,"featured_media":21476,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[780],"tags":[],"class_list":["post-21483","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"77","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"vmstat linux","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"21476","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/21483","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=21483"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/21483\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/21476"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=21483"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=21483"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=21483"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}