Ich zeige dir, wie du vmstat linux zielgerichtet liest: Du erkennst CPU-Engpässe, Speicherdruck, Swap und I/O-Wartezeiten in wenigen Sekunden. So interpretierst du die Spalten r, b, free, si/so, bi/bo und us/sy/id/wa/st sicher und leitest aus Mustern konkrete Maßnahmen ab – ohne Rätselraten, mit klaren Regeln.
Zentrale Punkte
- Run-Queue vs. Blockierungen: r zeigt CPU-Druck, b warnt vor I/O-Wartezeiten.
- Speicher real bewerten: free allein zählt nicht, si/so entscheidet.
- I/O im Blick: bi/bo sind unkritisch, wenn wa niedrig bleibt.
- CPU-Anteile lesen: us+sy hoch, id niedrig → hohe Auslastung.
- Baselines erstellen: Werte im Alltag mit Problemphasen vergleichen.
Was zeigt vmstat wirklich?
Vmstat bündelt Prozesszustände, Speicher, Swap, Block-I/O und CPU-Anteile in einem kompakten Output, der in Sekunden einen systemweiten Eindruck liefert. Ich lese zuerst „procs“ für r/b, danach „memory/swap“ für free, buff, cache sowie si/so. Dann prüfe ich „io“ mit bi/bo und schließe mit „cpu“ für us, sy, id, wa und optional st. Diese Reihenfolge hilft mir, Ursache und Wirkung auseinanderzuhalten: r hoch bedeutet Rechenlast, b hoch weist auf I/O-Wartezeiten hin, wa verknüpft CPU-Leerlauf mit I/O-Latenz. So erkenne ich, ob Rechenarbeit, Speicherknappheit oder Datenträger der Bremsklotz ist – und ich spare mir Umwege.
Start in 60 Sekunden: Aufrufe und Intervalle
Für eine Momentaufnahme seit dem Boot rufe ich „vmstat“ ohne Parameter auf, für akute Analysen nutze ich „vmstat 1“ oder „vmstat 5 12“ für zwölf Messpunkte alle fünf Sekunden und erhalte eine zeitliche Reihe. Wichtig: Die erste Zeile spiegelt Durchschnittswerte seit dem Systemstart, ich bewerte daher vor allem die folgenden Zeilen. Mit Delay/Count steuere ich Abtastrate und Dauer, etwa „vmstat 1 30“ bei kurzen Peaks. Bei nervösen Workloads setze ich 1–2 Sekunden, bei ruhigen Szenarien eher 5 Sekunden. Ich beobachte Trends, nicht Einzelframes, weil Muster die wahren Ursachen zeigen.
Prozesse lesen: r und b im Alltag
Die Spalte r zeigt laufbereite Threads, die auf CPU-Zeit warten, b zählt blockierte Threads, oft in I/O-Warte. Bleibt r deutlich über der Anzahl physischer Kerne, drängt sich ein CPU-Engpass auf; auf vier Kernen gilt r=8 über längere Zeit als klares Signal. Ein b-Wert größer 0 über längere Zeit spricht für zähe Datenträger, überforderte Datenbanken oder langsame Netz- oder Storage-Pfade. Ich korreliere r mit us+sy und id: ist id niedrig und r hoch, kämpft die CPU; ist wa hoch und b hoch, bremst I/O. So entscheide ich, ob ich Rechenleistung skaliere, Abfragen optimiere oder das Speichersystem prüfe.
Speicher deuten: free, buff, cache, swpd
Ein niedriger free-Wert ist auf Linux normal, denn der Kernel nutzt RAM aggressiv als Cache, was Dateizugriffe beschleunigt und echten Durchsatz bringt. Ich achte daher mehr auf swpd und die Swap-Streams si/so als auf free allein. Hoher cache ist gut, solange si/so fast immer 0 bleibt; erst dauerhafte Swap-Bewegung zeigt echten Druck. Tritt zusätzlich Latenz oder gar OOM auf, greife ich ein: RAM erhöhen, Prozesse rechtzeitig trimmen oder Cache- und JVM-Größen anpassen. Wichtig bleibt der Kontext: Workload, Speichergröße und NUMA-Layout bestimmen, was in deiner Umgebung als gesund gilt.
Swap-Aktivität: si und so einordnen
Die Spalten si/so messen den ständigen Strom zwischen RAM und Swap in KB/s und machen echten Speicherdruck sichtbar, nicht nur gefühlten Mangel. Kurze Peaks sind normal, etwa wenn selten genutzte Seiten verschoben werden. Kritisch wird es, wenn si oder so dauerhaft größer 0 bleiben; das verlangsamt alles, da jede Auslagerung zusätzliche I/O-Kosten erzeugt. Hohe so-Werte deuten auf aktives Auslagern hin, und Antwortzeiten steigen schmerzhaft. An diesem Punkt stoppe ich Ursachen: Speicherhunger reduzieren, RAM erweitern oder speicherintensive Dienste tunen.
Block-I/O verstehen: bi und bo
Mit bi/bo erkenne ich die Leseschreibrate in Blöcken pro Sekunde, doch ohne Kontext bewerte ich sie nicht über; entscheidend ist das Zusammenspiel mit wa. Hohe bi/bo und gleichzeitig hoher wa-Wert zeigen, dass Storage nicht mitkommt. Trifft hohe bi mit einer Datenbank zusammen, prüfe ich Abfrageprofile und Cache-Treffer, bevor ich Hardware austausche. Für tieferes Timing greife ich zu iostat und analysiere Warteschlangenlänge und Latenzen, sodass ich I/O‑Wait analysieren und Engpässe gezielt adressieren kann. Erst wenn wa niedrig bleibt, aber bi/bo dauerhaft explodiert, denke ich über Skalierung des Speichersystems nach.
CPU-Anteile us, sy, id, wa, st
Hohe us-Werte bei niedriger wa zeigen produktive Nutzarbeit, während hohe sy-Werte auf vielen Kernel-Overhead hindeuten, etwa zahllose kleine I/O-Operationen oder viele Kontextwechsel. Fällt id nahe 0 und bleibt es dort, läuft die CPU am Limit; kombiniert mit r hoch spricht das für Rechenlast. Steigt wa, wartet die CPU auf I/O – hier gewinnt Storage-Feintuning oft mehr als CPU-Upgrades. In VMs beachte ich st (steal): Hohe st-Werte verraten, dass der Hypervisor CPU-Zeit abzweigt, sodass ich mit dem Betreiber über Host-Auslastung spreche. Ich bewerte immer us+sy als Summe, denn diese zeigt die aktive Arbeit im System.
Schnellreferenz: Spalten und Richtwerte
Die folgende Tabelle nutze ich als kompakte Gedächtnisstütze, wenn ich vmstat-Ausgaben für eine erste Einschätzung querlese.
| Spalte | Bedeutung | Worauf ich achte |
|---|---|---|
| r | Laufbereite Threads | Dauerhaft > Kerne → CPU-Druck |
| b | Blockierte Threads | Konstant > 0 + wa hoch → I/O-Problem |
| free | Freier RAM | Niedrig ist ok, solange si/so ≈ 0 bleibt |
| buff/cache | FS-Buffer/Page-Cache | Viel Cache ist gut; kann freigegeben werden |
| si/so | Swap In/Out | Dauerhaft > 0 → echter Speicherdruck |
| bi/bo | Block-I/O | Nur kritisch, wenn wa gleichzeitig hoch ist |
| us/sy | User/Kernel | us+sy dauerhaft > 80% → hohe Last |
| id | Leerlauf | Nahe 0 über Zeit → CPU gesättigt |
| wa | I/O-Wait | Hoch mit b hoch → Storage als Ursache |
| st | Steal (VMs) | Hoch → Hypervisor nimmt CPU-Zeit |
Baselines und Dauerbeobachtung
Ich verlasse mich nicht auf Einzelschnappschüsse, sondern gleiche Werte gegen Baselines aus ruhigen Zeiten ab, damit ich Ausreißer sauber erkenne. „vmstat 1 60“ liefert mir eine Minute Lastprofil, das ich mit bekannten Normalphasen vergleiche. Für historische Sicht nutze ich sar/sysstat Monitoring, um Trends über Tage zu bewerten und Grenzwerte zu schärfen. Alerts setze ich konservativ: r relativ zu Kernen, si/so ungleich 0 über mehrere Intervalle, wa spürbar erhöht. So reagiere ich früh, bevor Nutzer Verzögerungen melden und bevor Peak-Phasen eskalieren.
Vmstat im Verbund mit weiteren Werkzeugen
Ich starte mit vmstat, entscheide anhand der Muster und vertiefe gezielt mit iostat, mpstat, pidstat oder Applikationsmetriken, damit ich Ursachen eindeutig zuordne. Zeigt vmstat I/O-Wartezeiten, messe ich mit iostat Latenzen und Warteschlangen je Gerät. Deutet r auf Kernlimit hin, zeigt mpstat Kernasymmetrien. Bei Prozess-Spitzenlast liefert pidstat Prozessanalyse die heftigsten Threads über Zeit. Erst die Korrelation mit Logs und Applikations-Timings verdichtet das Bild und führt mich zur echten Ursache.
Muster erkennen und handeln
Sehe ich r hoch, id niedrig und wa moderat, dann optimiert die Anwendung häufig zu rechenintensiv, weshalb ich Code oder Parallelität prüfe und CPU-Ressourcen plane, bevor ich Hardware anfordere. Treten b hoch, wa hoch und bi/bo hoch zusammen auf, ziehe ich Storage-Tuning, Query-Optimierung und Caching in Betracht. Bei niedriger free mit si/so größer 0 senke ich Speicherkonsum, streame Ergebnisse oder erhöhe RAM. Fallen us moderat und sy sehr hoch aus, schaue ich auf Paketfilter, Dateisystem-Optionen oder Treiber. Mit dieser Checkliste handle ich zügig und setze die Zeit dort ein, wo sie am meisten zählt.
Messfehler vermeiden: Sampling, Einheiten, erste Zeile
Ich werte die erste Zeile bewusst nicht für akute Störungen, denn sie mittelt seit dem Boot und glättet Peaks komplett. Außerdem orientiere ich die Abtastrate an der Ursachenhypothese: CPU-Spitzen fange ich mit 1‑Sekunden‑Intervallen ein, langsame Speicherlecks mit 5–10 Sekunden. Ich beachte Einheiten: si/so sind KB/s, bi/bo „Blöcke/s“ (historisch 1 KB je Block, je nach vmstat‑Version variabel). Ich prüfe, ob „vmstat -w“ (breite Ausgabe) Spaltenabschneidungen vermeidet und ob Taktfrequenzwechsel (P‑States, Turbo) die kurzfristige Lastwahrnehmung beeinflussen. Ich synchronisiere Messungen mit Applikationspeaks, statt blind „ganze Minuten“ zu betrachten.
System-Sektion entschlüsseln: in und cs
Neben procs/memory/swap/io/cpu zeigt vmstat auch „system“: in (Interrupts/s) und cs (Context Switches/s). Diese beiden Werte verraten mir viel über Kernel-Overhead.
- cs sehr hoch bei moderater Nutzlast: Thread‑Flatterei, zu kleine Worker‑Batches oder Lock‑Contention. Ich vergrößere Batchgrößen, reguliere Parallelität (Threadpools) und prüfe Scheduler‑/Mutex‑Hotspots.
- in sprunghaft hoch: Netz‑ oder Storage‑Interruptstürme, NAPI/Polling‑Effekte oder Timer‑Interrupts. Ich vergleiche mit sy‑Anteil und iostat‑Befunden, um Treiber oder Netzpfade zu prüfen.
- cs proportional zu r: Das deutet auf ständigen Kontextwechseldruck durch übermäßige Parallelität hin. Ich drossele die aktive Parallelität oder pinne Hot‑Threads auf Kerne.
Ich korreliere in/cs stets mit sy und b/wa: Nur im Verbund ergibt sich ein klares Bild, ob Kernelarbeit sinnvoll (z. B. Durchsatz) oder reiner Overhead ist.
Nützliche vmstat-Varianten und Optionen
Ich nutze vmstat flexibel, um ohne Toolwechsel zusätzliche Blickwinkel zu bekommen:
- vmstat -s: Summenzähler (z. B. seit Boot begonnene Prozesse, Major/Minor Page Faults). Ideal, um Lecks oder Fallzahlen über Zeitfenster zu vergleichen.
- vmstat -m: Slab‑Nutzung – hilft, Kernel‑Caches (Dentry/Inode, Netzwerk) als RAM‑Verbraucher einzuordnen.
- vmstat -d: Disk‑Events auf Summenebene. Kein Ersatz für iostat, aber gut für einen schnellen Reality‑Check.
- vmstat -S M: Einheiten umstellen (M/K), um Zahlen leichter zu lesen.
- vmstat -w: Breitere Spalten verhindern Abschneiden bei großen Zahlenkolonnen.
Ich kombiniere diese Varianten mit kurzen Intervallen, damit ich Events nicht verpasse und trotzdem die Übersicht behalte.
Container, VMs und Cgroups: Besonderheiten
In Containern interpretiere ich vmstat vorsichtig: Viele Kerneldaten sind hostweit, Limits kommen aus Cgroups. Hohe r‑Werte in einem Container spiegeln die Sicht des Namespaces, aber die reale CPU‑Zeit kann durch CPU‑Quota/CPU‑Shares begrenzt sein. Ich beziehe st (Steal) in VMs mit ein: Hoher st heißt, dass mir der Hypervisor Zeit entzieht – dann hilft selbst perfekte App‑Optimierung wenig, solange der Host überbucht ist. Bei Memory‑Limits in Cgroups kann si/so ausbleiben, obwohl der Container am Limit „zappelt“ (OOM‑Kills statt Swap). Ich prüfe daher zusätzlich OOM‑Logs und Cgroup‑Statistiken und gleiche vmstat‑Bilder mit den Limits ab.
NUMA und Affinität: Wenn Lokalität zählt
Auf NUMA‑Hosts prüfe ich r und us/sy pro Kern (mit mpstat) und beobachte, ob einzelne Sockets „heißlaufen“, während andere idlen. Unpassende Speicherlokalität führt zu mehr cs/sy und b/wa‑Anstiegen durch entfernte Speicherzugriffe. Ich teste CPU‑ und Speicher‑Affinity (cpuset, numactl), stelle große Heaps „interleaved“ oder strictly local ein und achte darauf, dass Hot‑Threads dort laufen, wo ihr Daten‑Footprint liegt. Ein stabiles NUMA‑Layout glättet cs, reduziert wa‑Ausreißer und erhöht die Planbarkeit unter Last.
Fehlinterpretationen vermeiden: wa und b sind mehr als „langsamer Datenträger“
wa steigt nicht nur bei klassischen Disk‑Latenzen: Auch NFS/Hochlatenz‑Netz, saturierter Object‑Storage, blockierende Cloud‑Volumes oder zähe Page‑Cache‑Writebacks drücken wa hoch. b zählt Tasks im ununterbrechbaren Schlaf (D‑State) – dazu gehören auch Hänger in Treibern, Netzwerkpfaden oder Filesystem‑Locks. Deshalb bewerte ich wa/b nie isoliert, sondern stets zusammen mit bi/bo und Applikations‑Timings. Ist wa hoch, bi/bo aber niedrig, liegt oft eine Warteabhängigkeit jenseits der reinen Geräte‑Durchsatzfrage vor (z. B. Locking, Remote‑I/O, Writeback‑Stau).
Tuning mit Augenmaß: Swappiness, Writeback, Scheduler
Ich ändere Kernel‑Tuner erst nach Messung und mit Rollback‑Plan:
- vm.swappiness: Niedriger dämpft proaktives Swappen, gut für latenzkritische Apps – zu niedrig kann Page‑Cache‑Druck erhöhen.
- vm.dirty_background_ratio / vm.dirty_ratio (oder *_bytes): Beeinflussen Writeback‑Zeitpunkte. Zu hohe Werte verursachen lange Writebursts (wa‑Spitzen), zu niedrige Werte erhöhen ständige Kleinflushes (sy/bo steigen).
- I/O‑Scheduler/Queue‑Depth: Auf NVMe andere Optima als auf HDD/RAID. Ich messe Latenz‑ und Durchsatz‑Trade‑offs mit iostat, bevor ich verändere.
- Netzpfade: Viele kleine Pakete/Interrupts treiben in/cs/sy. Grobe Tuninghebel sind GRO/LRO, RPS/RFS, IRQ‑Affinity – ich messe vorher/nachher.
Mein Ziel sind stabile, vorhersehbare Kurven in vmstat: us/sy ruhiger, wa/b niedriger, si/so nahe 0. Erst dann skaliere ich Hardware.
Playbook: 3-Minuten-Analyse mit vmstat
- 0:00–0:30 – „vmstat 1 30“: Erste Linie ignorieren, anschließend r/b, us/sy/id/wa sichten. Frage: CPU‑Limit (r hoch, id niedrig) oder I/O‑Limit (b/wa hoch)?
- 0:30–1:00 – Speicherblick: swpd und si/so prüfen. si/so dauerhaft > 0? → echter Speicherdruck. free nebensächlich.
- 1:00–1:30 – I/O‑Kontext: bi/bo vs. wa. Hohe bi/bo ohne wa? → I/O wird weggesteckt. Hohe wa bei moderaten bi/bo? → Latenz/Lock/Remote‑I/O.
- 1:30–2:00 – system‑Sektion: in/cs im Verhältnis zu sy. cs sehr hoch? → Kontextwechseldruck, Parallelität/Locking prüfen.
- 2:00–3:00 – Hypothese festzurren und Folgewerkzeug wählen: iostat bei I/O‑Indiz, mpstat bei Kernasymmetrien, pidstat bei Prozess‑Hotspots. Danach erst Tuning/Skalierung.
Erweiterte Muster aus der Praxis
- CPU‑Sättigung ohne hohe r: us+sy bei 90%+, id ≈ 0, r aber moderat → Single‑Thread‑Hotspot oder Affinitätsproblem. Lösung: Hot‑Pfad parallelisieren, Core‑Pinning prüfen.
- Swap‑Thrash: si und so gleichzeitig deutlich > 0, b/wa steigen, us fällt → RAM massiv zu klein oder Heap falsch dimensioniert. Maßnahmen: RAM erhöhen, Arbeitsset verkleinern, swappiness anpassen.
- Kernel‑Overhead: sy hoch, cs/in hoch, us moderat → viele kleine Syscalls/I/O. Abhilfe: Batchen, Syscall‑Reduktion, Filesystem‑Mount‑Optionen prüfen.
- Writeback‑Stau: wa hoch, bo hoch, kurze Wellen → dirty‑Grenzen zu hoch, Storage‑Latenz variiert. Writeback‑Tuning und I/O‑Scheduler sichten.
- Virtualisierungsdruck: st sichtbar, r schwankt, id „springt“ → Host teilt CPU. Lösung: vCPU‑Zuteilung/Placement prüfen, Overcommit reduzieren.
Grenzen von vmstat kennen
Vmstat ist ein hervorragender Frühwarnsensor, aber kein Mikroskop. Es zeigt mir, dass und wo es klemmt – nicht das einzelne Schuld‑File, die Query oder den Thread. Deshalb steige ich nach der vmstat‑Diagnose konsequent in Tiefenwerkzeuge ein, bestätige Hypothesen aus mehreren Richtungen und ändere dann nur eine Sache nach der anderen. So bleiben Verbesserungen messbar und reproduzierbar.
Zusammenfassung aus der Praxis
Mit vmstat erkenne ich binnen Sekunden, ob CPU, RAM, Swap oder I/O bremst, indem ich r, b, si/so, bi/bo und us/sy/id/wa/st im Zusammenspiel lese. Ich bewerte Trends statt Einzelwerte, vergleiche mit Baselines und ziehe bei Bedarf iostat, mpstat, pidstat sowie historische Messungen hinzu. Die erste Zeile ignoriere ich für akute Störungen und konzentriere mich auf die Folgezeilen mit fester Abtastrate. Ich entscheide datengetrieben: r relativ zu Kernen, si/so dauerhaft ungleich 0, wa anhaltend erhöht, us+sy nahe Vollauslastung. So leite ich schnell konkrete Maßnahmen ab und halte Systeme spürbar reaktiv.
