webentwicklung-frage-antwort-db.com.de

Auswählen eines Linux-E/A-Schedulers

Ich habe gelesen, dass es wahrscheinlich möglich ist, den E/A-Scheduler für ein bestimmtes Gerät in einem laufenden Kernel zu ändern, indem in/sys/block/[disk]/queue/scheduler geschrieben wird. Zum Beispiel kann ich auf meinem System sehen:

[email protected]:~$ cat /sys/block/sda/queue/scheduler 
noop anticipatory deadline [cfq] 

dass der Standardwert der vollständig faire Warteschlangen-Scheduler ist. Ich frage mich, ob es sinnvoll ist, alle vier Scheduler in meinen benutzerdefinierten Kernel aufzunehmen. Es scheint nicht viel Sinn zu haben, dass mehr als ein Scheduler kompiliert wird, es sei denn, der Kernel ist intelligent genug, um den richtigen Scheduler für die richtige Hardware auszuwählen, insbesondere den 'noop' - Scheduler für Flash-basierte Laufwerke und einen der anderen für herkömmliche Festplatte.

Ist das der Fall?

80

Wie in /usr/src/linux/Documentation/block/switching-sched.txt dokumentiert, kann der E/A-Scheduler auf einem bestimmten Blockgerät zur Laufzeit geändert werden. Es kann eine gewisse Latenzzeit geben, da die Anforderungen des vorherigen Schedulers alle geleert werden, bevor der neue Scheduler verwendet wird. Er kann jedoch problemlos geändert werden, selbst wenn das Gerät stark beansprucht wird.

# cat /sys/block/hda/queue/scheduler
noop deadline [cfq]
# echo anticipatory > /sys/block/hda/queue/scheduler
# cat /sys/block/hda/queue/scheduler
noop [deadline] cfq

Idealerweise gibt es einen einzigen Scheduler, der alle Anforderungen erfüllt. Es scheint noch nicht zu existieren. Der Kernel verfügt häufig nicht über ausreichende Kenntnisse, um den für Ihre Workload besten Scheduler auszuwählen:

  • noop ist oft die beste Wahl für speichergestützte Blockgeräte (z. B. RAM-Disks) und andere nicht rotierende Medien (Flash), bei denen der Versuch, E/A neu zu planen, Ressourcenverschwendung bedeutet
  • deadline ist ein einfacher Planer, der versucht, die Latenzzeit stark zu begrenzen
  • cfq versucht, die systemweite Fairness der E/A-Bandbreite aufrechtzuerhalten

Die Vorgabe war lange Zeit anticipatory, und sie erhielt viele Abstimmungen, wurde jedoch in 2.6.33 (Anfang 2010) entfernt. cfq wurde vor einiger Zeit zum Standard, da seine Leistung angemessen ist und Fairness ein gutes Ziel für Mehrbenutzersysteme (und sogar für Einzelbenutzer-Desktops) ist. Für einige Szenarien - Datenbanken werden häufig als Beispiele verwendet, da sie in der Regel bereits ihre eigenen speziellen Zeitplanungs- und Zugriffsmuster haben und häufig der most wichtige Dienst sind (also, wen interessiert die Fairness?) - anticipatory hat eine lange Geschichte der Anpassung an die beste Leistung dieser Workloads, und deadline leitet alle Anforderungen sehr schnell an das zugrunde liegende Gerät weiter.

107
ephemient

Es ist möglich, eine udev-Regel zu verwenden, damit das System den Scheduler auf der Grundlage einiger Merkmale des Hardwarekonzepts entscheiden kann.
Ein Beispiel für eine udev-Regel für SSDs und andere nicht rotierende Laufwerke könnte aussehen

# set noop scheduler for non-rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="noop"

in einer neuen udev-Regeldatei (z. B. /etc/udev/rules.d/60-ssd-scheduler.rules). Diese Antwort basiert auf dem debian-Wiki

Um zu prüfen, ob SSD-Festplatten die Regel verwenden, können Sie das Trigger-Attribut im Voraus prüfen: 

for f in /sys/block/sd?/queue/rotational; do printf "$f "; cat $f; done
19
Dani_l

Das Ziel der verschiedenen Kernel-Unterstützung besteht darin, dass Sie sie ohne Neustart ausprobieren können. Sie können dann Test-Workloads durch das Sytsem ausführen, die Leistung messen und diese dann als Standard für Ihre App festlegen.

Auf moderner Server-Hardware scheint nur der Noop überhaupt nützlich zu sein. Die anderen scheinen in meinen Tests langsamer zu sein.

7
MarkR

Sie können dies beim Booten festlegen, indem Sie den Parameter "Elevator" zur Kernel-Cmdline hinzufügen (z. B. in grub.cfg).

Beispiel:

elevator=deadline

Dadurch wird "Deadline" zum Standard-E/A-Scheduler für alle Blockgeräte.

Wenn Sie den Scheduler nach dem Booten des Systems abfragen oder ändern möchten oder einen anderen Scheduler für ein bestimmtes Blockgerät verwenden möchten, empfehle ich die Installation und Verwendung des Tools ioschedset, um dies zu vereinfachen.

https://github.com/kata198/ioschedset

Wenn Sie auf Archlinux sind, ist es in aur verfügbar:

https://aur.archlinux.org/packages/ioschedset

Einige Verwendungsbeispiele:

# Get i/o scheduler for all block devices
[[email protected] ~]$ io-get-sched
sda:    bfq
sr0:    bfq

# Query available I/O schedulers
[[email protected] ~]$ io-set-sched --list
mq-deadline kyber bfq none

# Set sda to use "kyber"
[[email protected] ~]$ io-set-sched kyber /dev/sda
Must be root to set IO Scheduler. Rerunning under Sudo...

[Sudo] password for username:
+ Successfully set sda to 'kyber'!

# Get i/o scheduler for all block devices to assert change
[[email protected] ~]$ io-get-sched
sda:    kyber
sr0:    bfq

# Set all block devices to use 'deadline' i/o scheduler
[[email protected] ~]$ io-set-sched deadline
Must be root to set IO Scheduler. Rerunning under Sudo...

+ Successfully set sda to 'deadline'!
+ Successfully set sr0 to 'deadline'!

# Get the current block scheduler just for sda
[[email protected] ~]$ io-get-sched sda
sda:    mq-deadline

Die Verwendung sollte selbsterklärend sein. Die Tools sind Standalone und benötigen nur Bash.

Hoffe das hilft!

EDIT: Disclaimer, das sind Skripte, die ich geschrieben habe.

0
Tim Savannah