Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.
Beide Seiten, vorherige Überarbeitung Vorherige Überarbeitung | |||
der_richtige_io_sheduler [2010/11/08 09:43] – 192_168_1.33 | der_richtige_io_sheduler [2017/04/01 17:22] (aktuell) – gelöscht admin | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
- | * " | ||
- | |||
- | * " | ||
- | |||
- | * " | ||
- | |||
- | * " | ||
- | |||
- | Der cfq ist der komplexeste der I/O Scheduler, reagiert aber am | ||
- | schnellsten. Daher ist es für den typischen Desktop-Betrieb | ||
- | normalerweise der am besten geeignete I/O Scheduler. In vielen | ||
- | Linux-Distris wird er daher auch als Default-Scheduler eingesetzt. | ||
- | |||
- | Allerdings scheduled der cfq die Requests nicht optimal aus der Sicht | ||
- | der Arbeit welche die Disk zu erledigen hat. Hier ist der anticipatory | ||
- | normalerweise am effizientesten - insbesondere wenn Batch-Jobs laufen | ||
- | die ihrerseits jede Menge sequenzielle Dateien (gleichzeitig) | ||
- | bearbeiten. Auch zum Ansehen von Videos etc. ist er wohl der geeignetste. | ||
- | |||
- | Der deadline wiederum glänzt bei völligen Random-Zugriffen, | ||
- | allem bei Datenbanken oft vorkommen. Hier sorgt er dafür, dass die Seeks | ||
- | minimiert werden welche für das Durchführen der Random-Zugriffe | ||
- | erforderlich sind. Zwar ist der anticipatory dem deadline sehr ähnlich, | ||
- | aber durch die kleinen Wartepausen die er einlegt um " | ||
- | erkennen" | ||
- | anticipatory Zeit welche der deadline nicht vergeudet. | ||
- | |||
- | Wenn Datenbankzugriffe aber nicht andauernd erfolgen, kann der | ||
- | anticipatory doch wieder besser sein: Bei Datenbankzugriffen zwar etwas | ||
- | langsamer, kann er aber zwischendurch bei sequenziellen Zugriffen wieder | ||
- | Zeit und Seeks sparen. | ||
- | |||
- | Wenn neben den Datenbanken und Batch-Jobs aber auch noch " | ||
- | gearbeitet werden soll, empfiehlt sich wieder der cfq: Durch seine | ||
- | Zeitscheiben werden auch sequenzielle Jobs - zumindest innerhalb der | ||
- | Zeitscheibe - halbwegs effizient abgearbeitet, | ||
- | langen Zeitscheiben kann er aber auch Datenbanken ausreichend effizient | ||
- | bedienen obwohl nicht ganz so gut wie der deadline. Vor allem aber | ||
- | verhungern während dessen keine interaktiven Benutzerprozesse. | ||
- | |||
- | Ich werde aus diesen Erkenntnissen die Konsequenz ziehen, den cfq als | ||
- | Default-Scheduler einzustellen. | ||
- | |||
- | Wenn ich aber fette Batch-Jobs laufen lasse, wie große emerge-Orgien wo | ||
- | der Compiler ständig sequeziell Source-Dateien liest und Object-Files | ||
- | erzeugt, werde ich temporär auf den anticipatory umschalten. Dasselbe | ||
- | gilt beim Movie-Ansehen, | ||
- | durch die Gegend kopiert werden sollen und mir Interaktivität | ||
- | währenddessen nicht so wichtig ist. | ||
- | |||
- | Wenn ich hingegen einen Rechner als dezidierten Datenbankserver unter | ||
- | hoher Last einsetze, ist hingegen der " | ||
- | dürfte auch OK sein wenn die Last nicht ganz so hoch ist.) | ||
- | |||
- | Tja, soweit meine Erkenntnisse. | ||
- | |||
- | Hier noch wie man die Scheduler umschaltet (geht im laufenden Betrieb): | ||
- | |||
- | < | ||
- | #! /bin/sh | ||
- | SCHEDULER=${1: | ||
- | lsmod | grep " | ||
- | modprobe " | ||
- | } | ||
- | for D in / | ||
- | S=" | ||
- | test -e " | ||
- | echo " | ||
- | echo " | ||
- | done | ||
- | < | ||
- | Aufruf: | ||
- | <pre> | ||
- | set_iosched cfq | ||
- | set_iosched # setzt ebenfalls cfq | ||
- | set_iosched noop | ||
- | set_iosched anticipatory | ||
- | set_iosched deadline | ||
- | </ | ||
- | |||
- | Oder für ein Blockdevice setzten: | ||
- | | ||
- | echo anticipatory > / | ||