# Subsystem Statistics: Die Wahrheit über I/O und Memory

TL;DR / Management Summary Während htop uns zeigt, wer Ressourcen verbraucht, verraten uns iostat und vmstat, wie die Hardware darauf reagiert. Ein Senior Admin nutzt diese Tools, um tiefgehende Engpässe zu finden: Arbeitet die Festplatte an ihrem Limit (iostat)? Muss das System ständig Seiten in den Swap auslagern (vmstat)? Diese Befehle liefern die Rohdaten, um Hardware-Fehlkäufe oder Fehlkonfigurationen objektiv nachzuweisen.

# 1. Einführung & Architektur

Blick auf die Kernel-Zähler.

Der Linux-Kernel pflegt interne Zähler für jeden I/O-Vorgang und jede Speicherseite.

# Die Analyse-Ebenen (Mermaid)

graph TD
    A[Linux Kernel] --> B[Subsystem Statistics]
    B --> C[vmstat: Virtual Memory & CPU]
    B --> D[iostat: Storage I/O]
    C --> C1[swpd: Swapping activity]
    C --> C2[cs: Context switches]
    D --> D1[tps: Transactions per sec]
    D --> D2[await: Latency in ms]
    D --> D3[%util: Disk Utilization]

# 2. iostat: Die Disk-Analyse

Wie hart arbeiten die Platten?

Teil des Pakets sysstat.

# Nutzung

# Zeige Statistiken alle 2 Sekunden, in MB/s
iostat -m 2

# Wichtige Metriken (KPIs)

• %util: Wie viel Prozent der Zeit war die Disk beschäftigt? (100% = Sättigung).
• await: Die durchschnittliche Zeit (in ms), die ein I/O-Request gedauert hat. (Werte > 10ms auf SSDs deuten auf Probleme hin!).
• tps: Transactions per Second (IOPS).

# 3. vmstat: Der System-Gesundheitscheck

Speicher und Scheduler.

# Nutzung

# Zeige 5 Reports im 1-Sekunden Takt
vmstat 1 5

# Wichtige Spalten

• si / so (Swap In / Out): Wenn diese Werte ungleich 0 sind, hat Ihr System zu wenig RAM.
• cs (Context Switches): Sehr hohe Werte (> 50.000) deuten auf ineffiziente Applikationen hin, die zu viele Threads nutzen.
• r (Running): Anzahl der Prozesse, die auf CPU-Zeit warten.

# 4. Day-2 Operations: Langzeit-Analyse

Den Verlauf verstehen.

Nutzen Sie den Dienst sar (System Activity Reporter), der ebenfalls zum sysstat Paket gehört. Er speichert die Daten von iostat und vmstat im Hintergrund ab.

# Was war gestern um 14:00 Uhr mit der CPU los?
sar -q -f /var/log/sa/sa$(date +%d -d "yesterday")

# 5. Troubleshooting & “War Stories”

Bugs in der Hardware finden.

# Story 1: “Die sterbende SSD”

Symptom: Der Webserver ist langsam, CPU-Last ist bei 1%. Ursache: iostat -x zeigt einen await Wert von 500ms bei einer SSD. Die Hardware hat interne Latenzprobleme durch defekte Flash-Zellen (Read-Retry-Loops). Lösung: Sofortiger Tausch der Disk. Ohne iostat hätte der Admin ewig in der Applikations-Logik gesucht.

# Story 2: “Context Switch Hell”

Symptom: Ein Hochleistungs-Server erreicht nur 50% des erwarteten Durchsatzes, obwohl genug RAM und CPU frei sind. Ursache: vmstat zeigt 200.000 Context Switches pro Sekunde. Die Applikation (z.B. ein falsch konfigurierter Java-Server) wechselt ständig zwischen zu vielen kleinen Threads. Lösung: Thread-Pool der Applikation begrenzen. Weniger Threads führen hier oft zu mehr Durchsatz.

# 6. Fazit & Empfehlung

• Pflicht: Installieren Sie das Paket sysstat auf jedem produktiven SLES/Arch Server.
• Wartung: Nutzen Sie iostat vor und nach Hardware-Upgrades, um den Performance-Gewinn zu validieren.
• Wahl: Nutzen Sie vmstat als ersten schnellen Check, wenn ein System sich “zäh” anfühlt.

# Anhang: Cheatsheet