# I/O Scheduling: Die Vorfahrt auf der Datenautobahn regeln

TL;DR / Management Summary Jedes Mal, wenn eine Applikation Daten von der Disk anfordert, entscheidet der I/O Scheduler, in welcher Reihenfolge diese Anfragen abgearbeitet werden. Während wir bei alten HDDs (rotierend) die Kopfbewegung minimieren mussten, liegt der Fokus bei modernen SSDs und NVMe auf minimaler Latenz und Parallelität. In diesem Modul lernen wir, wie wir mit mq-deadline, Kyber und BFQ die Performance für Datenbanken, Webserver und Backup-Ziele optimieren.

# 1. Einführung & Architektur

Vom Block-Layer zum Controller.

Linux nutzt heute den Multi-Queue Block Layer (blk-mq). Er erlaubt es, I/O-Anfragen über mehrere CPU-Kerne parallel an moderne Hardware weiterzureichen.

# Die Scheduler im Vergleich (Mermaid)

graph TD
    A[Application Requests] --> B{blk-mq Layer}
    B --> C[mq-deadline: Reliable / Standard]
    B --> D[kyber: Low Latency / Fast SSDs]
    B --> E[bfq: Interactive / Slow Disks]
    B --> F[none: NVMe / Passthrough]
    C/D/E/F --> G[Disk Controller]

# 2. Welcher Scheduler für welche Hardware?

Die strategische Wahl.

# 1. NVMe-Speicher

Nutzen Sie none. NVMe-Platten sind so schnell und parallelisierbar, dass jede zusätzliche Logik im Kernel (Scheduling) nur unnötigen Overhead und Latenz erzeugt.

# 2. Standard-SSDs (SATA/SAS)

Nutzen Sie mq-deadline oder kyber.

• mq-deadline: Garantiert, dass kein Request verhungert (Starvation prevention). Ideal für Server.
• kyber: Von Facebook entwickelt für extrem niedrige Latenzen unter Hochlast.

# 3. Rotierende HDDs

Nutzen Sie bfq (Budget Fair Queuing). Er ist komplexer und versucht, jedem Prozess einen fairen Anteil am I/O-Durchsatz zu geben – ideal für Desktops oder Fileserver auf HDD-Basis.

# 3. Konfiguration zur Laufzeit

Den Hebel umlegen.

Prüfen Sie, welche Scheduler verfügbar sind (der aktive steht in Klammern):

cat /sys/block/sda/queue/scheduler
# Output: [mq-deadline] kyber bfq none

# Scheduler ändern

# Setze 'kyber' für Device sda
echo "kyber" | sudo tee /sys/block/sda/queue/scheduler

# 4. Day-2 Operations: Rotational vs. Non-Rotational

Dem Kernel die Wahrheit sagen.

Manchmal erkennt der Kernel (besonders in VMs) nicht korrekt, ob ein Device eine SSD oder eine HDD ist.

# SSD-Modus erzwingen

# 0 = SSD (kein rotierender Kopf), 1 = HDD
echo 0 | sudo tee /sys/block/sda/queue/rotational

Dies deaktiviert im Kernel unnötige Optimierungen für Kopfbewegungen.

# 5. Troubleshooting & “War Stories”

Wenn die Disk hakt.

# Story 1: “Der hängende Backup-Host”

Symptom: Sobald das nächtliche Backup startet, reagieren interaktive Befehle (ls, vi) auf dem Server erst nach 5 Sekunden Verzögerung. Ursache: Der Standard-Scheduler (mq-deadline) priorisiert hohen Durchsatz für den Backup-Stream, lässt aber kleine, interaktive Requests verhungern. Lösung: Wechseln Sie zu BFQ. Er erkennt interaktive Tasks und gibt ihnen Vorrang gegenüber massiven sequenziellen Schreibvorgängen.

# Story 2: “NVMe Performance-Einbruch in VMs”

Symptom: Eine NVMe-Disk in einer Proxmox-VM erreicht nur 50% der theoretischen IOPS. Ursache: Der Gast nutzt mq-deadline. Da der Hypervisor bereits ein eigenes Scheduling macht, führt die doppelte Logik im Gast zu Latenz-Spikes. Lösung: Stellen Sie den Scheduler in der VM auf none. Lassen Sie die Hardware oder den Hypervisor die Arbeit machen.

# 6. Fazit & Empfehlung

• NVMe: Immer none.
• Virtuelle Maschinen: Immer none oder mq-deadline.
• Automation: Nutzen Sie udev-Regeln, um den richtigen Scheduler automatisch beim Booten basierend auf dem Disk-Typ zu setzen. Datei: /etc/udev/rules.d/60-ioschedulers.rules

  ACTION=="add|change", KERNEL=="sd[a-z]|mmcblk[0-9]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="kyber"

# Anhang: Cheatsheet