Best Practice I/O-Scheduler (war: Re: Kann nicht zu CFQ-Scheduler wechseln)
Marc Haber - 09.01.23, 18:09:24 CET:
> >In einer VM ist "none" oftmals die beste Wahl, da der Kernel in der
> >VM keine Ahnung über die Queue und Struktur des Datenspeichers hat.
> >
> >In der Vergangenheit haben Scheduler in VMs und außerhalb der VM sehr
> >oft gegeneinander gearbeitet, so dass es Best Practice war und ist,
> >in der VM einfach nur "none" (oder früher "deadline") als Scheduler
> >zu haben.
>
> Ich habe mir mal eine Ubuntu- und eine Debian-VM in der Hetznercloud
> gestartet, beide haben als Scheduler mq-deadline gesetzt. Wo kann ich
> über diese Best Practice nachlesen?
In meinem Kurs :)
Vereinzelt auch in der Kernel-Dokumentation:
https://www.kernel.org/doc/html/latest/block/blk-mq.html?
highlight=mq+deadline
https://www.kernel.org/doc/html/latest/block/index.html
So ganz vollständig oder zumindest übersichtlich ist das jedoch nicht.
Möglicherweise auch an anderen Stellen im den Weiten des Netzes.
Allerdings ist wie in der Kernel-Dokumentation da auch nicht alles auf
dem neuesten Stand.
Wobei "mq-deadline" dem "none" schon relativ nahe kommt. Und bereits in
der Vergangenheit in Bezug auf die alten "Single Queue"-Schedulern gab
es unterschiedliche Ansichten. So hat ja Ubuntu auf den deadline
umgeschwenkt, während andere Distributionen, so wie ich mich erinnere
lange Zeit auch Debian, standardmäßig den cfq hatte. Bei zumindest
einigen XFS-Entwicklern war der cfq nicht so beliebt. Denn da gibt es
mindestens drei größere Versionen von. Da gab es so ein Spiel: XFS-
Entwickler passten XFS an, damit es mit cfq besser klappt, und dann
haben cfq-Entwickler den wieder so geändert, dass es nicht so gut
klappte¹.
Grundsätzlich halte ich es mit der Regel, mich auf die Intelligenz zu
verlassen, die am nächsten an der Hardware ist. So weiß OnTAP auf einer
NetApp einfach mehr über die eingesetzten Festplatten oder SSDs, die
Größe und den Aufbau von NV-RAM/Flash-Caches als das oben drüber
laufende Linux. Ähnliches gilt für einen Hypervisor. Der ist näher an
der Hardware als die VM. Und die üblichen intelligenten SATA/NVMe-SSDs
machen mit den Daten ja ohnehin so in etwa das, was sie wollen. Zum
Glück klappt das in der Regel so einigermaßen und zumindest meine BTRFS-
Dateisysteme sind der Meinung, dass die Daten Bit für Bit noch stimmen
:)
[1] XFS FAQ, Q: "I want to tune my XFS filesystems for <something>"As of
kernel 3.2.12, the default i/o scheduler, CFQ, will defeat much of the
parallelization in XFS. " https://web.archive.org/web/20220902080136/
https://xfs.org/index.php/XFS_FAQ
> Was ist denn der Debian-Weg um den IO-Scheduler zu setzen?
> /etc/default/grub und die passende Kommandozeilenoption?
Das kommt drauf an, ob global für alle Geräte oder für unterschiedliche
Geräte getrennt. Für Festplatten, SATA- und NVMe-SSDs, für LUNs können
unterschiedliche Einstellungen Sinn machen. Global geht über GRUB. Lokal
via udev-Regel oder sysfs. Ich hab hier beispielsweise für ein ThinkPad
T14 AMD Gen 1 für eine Samsung 980 Pro SSD nach Tests Folgendes
eingestellt:
% cat /etc/sysfs.d/block.conf
block/nvme0n1/queue/scheduler = none
https://www.kernel.org/doc/html/latest/block/switching-sched.html
Auch wenn ich ich das eher für eine Mikro-Optimierung halte, gerade
angesichts 32 GiB Hauptspeicher in diesem Laptop, das Linux oft genug
selbst für den Pagecache nicht mal komplett verbraucht². Die Latenzen
waren damit jedoch am geringsten.
Bei Festplatten macht cfq oder bfq laut meinen Messungen durchaus Sinn.
[2] Ich hab für das gebrauchte, jedoch im Grunde neuwertige Laptop wenig
mehr als die Hälfte des damaligen Neupreises für das reguläre, Nicht-
Campus-Modell bezahlt. Da war das dann auch schon egal.
Ciao,
--
Martin
Reply to: