Optimierung des Linux-I/O-Schedulers: mq-deadline, none und BFQ

Der Linux-I/O-Scheduler bestimmt die Reihenfolge, in der Lese- und Schreibanforderungen Ihr Speichergerät erreichen, und die richtige Wahl hängt fast ausschließlich von Ihrer Hardware ab. Verwenden Sie none für NVMe, mq-deadline für SATA-SSDs und HDDs mit gemischten Workloads und bfq wenn Sie verhindern müssen, dass ein Prozess die anderen ausbremst. Dieser Leitfaden behandelt, wie die drei wichtigsten Scheduler funktionieren, wie Sie einen an Ihre Workload anpassen und wie Sie die Ergebnisse optimieren und überprüfen können.

Wenn Sie vor dem Lesen eine praktische Anleitung wünschen, behandelt dieses Video die Grundlagen des Wechsels und Testens von Schedulern über das Terminal.

Wie sich mq-deadline, none und BFQ unterscheiden

Jeder Scheduler verarbeitet Anfragen nach einer anderen Strategie. Wenn Sie wissen, wie sie sich unterscheiden, können Sie eine bewusste Wahl treffen, anstatt einfach das zu verwenden, was der Kernel beim Booten ausgewählt hat.

mq-deadline

Der mq-deadline Scheduler stellt sicher, dass keine Anfrage unbegrenzt wartet. Er unterhält separate, sortierte Warteschlangen für Lese- und Schreibvorgänge, ordnet diese nach logischer Blockadresse (LBA), um die Suchzeit zu verkürzen, und setzt Fristen durch: standardmäßig 500 ms für Lesevorgänge und 5 Sekunden für Schreibvorgänge. Wenn eine Anfrage ihre Frist erreicht, springt sie an den Anfang der Warteschlange.

Lesevorgänge haben Vorrang vor Schreibvorgängen, da Lesevorgänge die Anwendung in der Regel blockieren, während Schreibvorgänge asynchron abgewickelt werden. Um zu verhindern, dass Schreibvorgänge vollständig ausgehungert werden, bearbeitet der Scheduler nach einer festgelegten Anzahl von Lesevorgängen einen Stapel überfälliger Schreibvorgänge. Das Ergebnis ist eine konstant niedrige Latenz, was ihn besonders geeignet für Datenbankserver und alle Workloads macht, die Lese- und Schreibvorgänge mischen.

none

Der none Scheduler macht fast gar nichts. Er leitet Anfragen direkt in First-In-First-Out-Reihenfolge an das Gerät weiter, ohne Neuanordnung, Zusammenführung oder Priorisierung. Das passt zu modernen NVMe-Laufwerken, die ihre eigenen internen Warteschlangen verwalten und Zehntausende von laufenden Anfragen gleichzeitig verfolgen können. Durch das Weglassen der Software-Scheduling-Schicht entsteht der kürzestmögliche Weg von der Anwendung zum Gerät, was genau das ist, was NVMe-Workloads mit hohem Durchsatz benötigen.

Der Haken daran ist, dass dies nur funktioniert, wenn die Hardware selbstständig intelligent planen kann. Bei HDDs oder SATA-SSDs mit flachen Warteschlangen verschlechtert das Überspringen der Software-Neuanordnung die Leistung in der Regel, anstatt sie zu verbessern.

BFQ

BFQ (Budget Fair Queuing) stellt Fairness in den Vordergrund. Anstelle von Zeitscheiben weist es jedem Prozess ein Budget zu, das in Festplattensektoren gemessen wird. Große sequenzielle Lesevorgänge erhalten größere Budgets, um den Durchsatz aufrechtzuerhalten, während latenzempfindliche Aufgaben kleinere Budgets erhalten, damit sie schnell bedient werden, und eine Rückkopplungsschleife passt die Budgets während der Ausführung an.

BFQ sorgt dafür, dass interaktive Aufgaben auch unter hoher Last reaktionsschnell bleiben, sodass die Videowiedergabe oder eine Datenbankabfrage flüssig verläuft, während im Hintergrund eine große Dateiübertragung läuft. Diese Fairness kostet CPU-Leistung. Der Overhead pro Anfrage beträgt etwa 1,9 Mikrosekunden, was etwa dem Dreifachen von mq-deadline entspricht, und auf einem langsameren ARM-Kern begrenzt dieser Overhead den Durchsatz deutlich unter das, was derselbe Scheduler auf einem schnellen x86-Chip erreicht. Auf Servern, auf denen der reine Durchsatz und die CPU-Effizienz am wichtigsten sind, ist dieser Kompromiss schwer zu rechtfertigen.

Auswahl eines Schedulers für Ihre Workload

Zwei Faktoren entscheiden über den richtigen Scheduler: Ihre Speicherhardware und das Zugriffsmuster Ihrer Anwendung. Beginnen Sie mit der Hardware. Wenn das Gerät Anfragen bereits neu ordnet, wie beispielsweise ein NVMe-Laufwerk mit entsprechender Firmware, verursacht die Software-Planung nur zusätzlichen Overhead, sodass none gewinnt. Bei rotierenden Festplatten, bei denen die Suchzeit dominiert, reduziert die Software-Neuanordnung die Latenz, daher mq-deadline oder bfq sind die bessere Wahl. SATA-SSDs liegen dazwischen: schneller als HDDs, aber ohne die tiefen Warteschlangen von NVMe, weshalb mq-deadline gut passt.

Die gleiche Logik gilt, wenn bereits etwas anderes die Planung für Sie übernimmt. Gast-VMs auf virtio-blk verlassen sich auf den Host für die E/A-Planung, und Hardware-RAID-Controller mit Write-Back-Cache optimieren ihre eigene Reihenfolge. In beiden Fällen none wird vermieden, dass die Arbeit doppelt bezahlt wird.

Das Zugriffsmuster ist der zweite Faktor. Eine Datenbank, die Tausende von zufälligen 4K-Lesevorgängen pro Sekunde durchführt, hat nichts mit einem Trainingsjob gemeinsam, der große sequenzielle Blöcke von einem NVMe-Array streamt, und beide benötigen unterschiedliche Scheduler. Die folgende Tabelle ordnet gängige Workloads einem Ausgangspunkt zu.

Es gibt eine Ausnahme, die es wert ist, erwähnt zu werden. Selbst bei NVMe kann mq-deadline kann none durch die Durchsetzung strenger Fristen und die Vermeidung gelegentlich verzögerter Anfragen

Ändern und Anpassen von Scheduler-Parametern

Sowohl das Umschalten der Scheduler als auch die Anpassung ihrer Parameter erfolgt über sysfs, wobei zum Testen einer Änderung kein Neustart erforderlich ist.

Wechseln des aktiven Schedulers

Prüfen Sie, was für ein Gerät verfügbar ist, wobei der Wert in Klammern der aktive ist:

cat /sys/block/sda/queue/scheduler

Wechseln Sie zur Laufzeit zu einem anderen Scheduler. Dies wird sofort wirksam, bleibt jedoch nach einem Neustart nicht erhalten:

echo bfq | sudo tee /sys/block/sda/queue/scheduler

Wenn bfq nicht aufgeführt ist, laden Sie das Modul zuerst:

sudo modprobe bfq

Um eine Auswahl dauerhaft zu machen, verwenden Sie eine udev-Regel anstelle des alten elevator= Kernel-Parameter, der unter RHEL 9 und ähnlichen Versionen den Scheduler nicht mehr ändert. Diese Regel setzt mq-deadline für alle nicht rotierenden SCSI-Festplatten in /etc/udev/rules.d/60-io-scheduler.rules:

ACTION=="add|change", SUBSYSTEM=="block", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="mq-deadline"

Laden Sie sie neu und wenden Sie sie ohne Neustart an:

sudo udevadm control --reload-rules && sudo udevadm trigger

Auf RHEL-basierten Systemen erfüllen TuneD-Profile dieselbe Aufgabe über systemweite Profile anstelle von gerätespezifischen Regeln.

Parameter, die eine Optimierung wert sind

Jeder Scheduler stellt seine Einstellmöglichkeiten unter /sys/block/<device>/queue/iosched/. Für mq-deadlinesind die Deadlines die wichtigsten Hebel. Latenzempfindliche Datenbanken auf SATA-SSDs profitieren von kürzeren Deadlines:

echo 100 | sudo tee /sys/block/sda/queue/iosched/read_expire
echo 1000 | sudo tee /sys/block/sda/queue/iosched/write_expire

Bei bfq auf Systemen mit hohem Durchsatz erhöht das Deaktivieren der Latenz-Heuristik den Durchsatz:

echo 0 | sudo tee /sys/block/sda/queue/iosched/low_latency
echo 0 | sudo tee /sys/block/sda/queue/iosched/slice_idle

Bei Shared Hosting lässt sich BFQ gut mit cgroups v2 kombinieren. Durch die Zuweisung io.weight Werte können Sie beispielsweise einem Datenbankprozess das Zehnfache des I/O-Anteils eines Backup-Jobs zuweisen, damit Hintergrundaufgaben den interaktiven Datenverkehr nicht überlagern. Unabhängig von Ihren Änderungen summieren sich die höheren Kosten pro Anfrage von BFQ auf CPU-gebundenen Systemen mit hohen IOPS, führen Sie daher vor der endgültigen Festlegung einen Benchmark durch.

Überprüfung der Leistung nach der Optimierung

Erfassen Sie immer einen Ausgangswert, bevor Sie Änderungen vornehmen. Ohne diesen können Sie nicht feststellen, ob eine Optimierung geholfen hat.

fio ist das Standardwerkzeug hierfür. Es reproduziert spezifische Workload-Muster durch Einstellungen für Blockgröße, Warteschlangentiefe und I/O-Engine. Geben Sie immer --direct=1 , damit der Seiten-Cache umgangen wird und der Scheduler sowie das Gerät direkt gemessen werden, anstatt zwischengespeicherte Lesevorgänge. Passen Sie den Test an die tatsächliche Arbeitslast an:

Führen Sie denselben Test mit iodepth Werte von 1 bis 256 durch, um den Sättigungspunkt des Geräts zu ermitteln – die Tiefe, bei der die IOPS nicht weiter steigen und die Latenz in die Höhe schnellt. Für die Live-Überwachung nach einer Änderung iostat -x 1 berichten Sie die Metriken, auf die es ankommt: r_await sowie w_await für die Latenzen beim Abschluss von Lese- und Schreibvorgängen aqu-sz für die durchschnittliche Warteschlangentiefe sowie %util für die Geräteauslastung. Wenn %util bei fast 100 Prozent liegt, ist die Hardware das limitierende Element, und keine Änderung des Schedulers wird Abhilfe schaffen.

Um die Softwarekosten von den Hardwarekosten zu trennen, führen Sie blktrace mit btt aus. Dies unterteilt die Latenz in Q2D, die in der Software-Warteschlange verbrachte Zeit, und D2C, die Zeit, die das Gerät benötigt, um die Anforderung zu bearbeiten. Wenn Q2D dominiert, ist der Scheduler Ihr Engpass. Wenn D2C dominiert, ist es die Hardware.

Ein Punkt, den Sie beim Lesen der Ergebnisse beachten sollten: Die Wahl des Schedulers beeinflusst meist den Randbereich der Latenzverteilung, nicht den Median. Der Wechsel von none auf mq-deadline auf NVMe kann die Median-Latenz um einige Mikrosekunden erhöhen, während die p99- und p999-Latenz um die Hälfte reduziert wird. Für benutzerseitige Dienste, die an SLAs gebunden sind, lohnt sich dieser Kompromiss fast immer, weshalb die Messung der Latenz am Ende der Verteilung und nicht des durchschnittlichen Durchsatzes der Sinn der Übung ist.

Die Wahl des richtigen Schedulers

Bei der Scheduler-Optimierung geht es darum, den Algorithmus an die Hardware und das Zugriffsmuster anzupassen und dies anschließend durch Messungen zu belegen. Die Kurzfassung:

• NVMe: Verwenden Sie none und überlassen Sie die Warteschlangenverwaltung der Firmware.
• SATA-SSDs und HDDs mit gemischter E/A: Verwenden Sie mq-deadline für vorhersehbare Latenz.
• Gemeinsam genutzte oder Multi-Tenant-Hosts: Verwenden Sie bfq , um zu verhindern, dass eine Workload die anderen ausbremst.
• Beobachten Sie die Tail-Latenz, nicht den Median: Änderungen am Scheduler zeigen sich bei p99 und p999, daher sollten Sie diese Werte messen.
• Sorgen Sie für Persistenz: Verwenden Sie udev-Regeln oder TuneD, niemals den elevator= Parameter.

Um das Beste aus jedem Scheduler herauszuholen, braucht es zunächst einmal Hardware, die mithalten kann. Wenn Sie NVMe-gestützte Server benötigen, die für Workloads mit hohem Durchsatz und geringer Latenz ausgelegt sind, sehen Sie sich die VPS-Optionen von FDC an.