Device-Layer

Auf dem untersten Layer arbeitet schließlich ein Device-Treiber (beispielsweise SCSI) die Dispatch-Queue des Block-Layers ab. Die Firmware der eingesetzten Festplatte ist dafür verantwortlich, dass die Daten dort landen, wo sie hin sollen. Die Software positioniert beispielsweise die Schreib-/Leseköpfe der Hardware, was auch als Seeking bezeichnet wird. Durchschnittliche Seek-Zeiten von aktuellen Server-Systemen liegen dabei bei unter 5 ms.

Die meisten Anpassungen auf Betriebssystem-Ebene erfolgen dabei auf dem Dateisystem- und dem Block-Layer. Tools zum Monitoring der I/O-Aktivitäten sind beispielsweise vmstat, iostat oder sar. Der System Activity Reporter (sar) eignet sich dabei besonders gut für Langzeit-Überwachungen. Folgende Metriken gibt iostat aus, wenn es mit der Option "-x" (erweiterte Statistiken) aufgerufen wird:

- rrqm/s: Anzahl Leseanforderungen pro Sekunde vor dem Senden an die Disk

- wrqm/s: Anzahl Schreibanforderungen pro Sekunde vor dem Senden an die Disk

- r/ss: Ausgeführte Leseoperationen pro Sekunde

- w/s: Ausgeführte Schreiboperationen pro Sekunde

- rsec/s: Gelesene Sektoren pro Sekunde

- wsec/s: Geschriebene Sektoren pro Sekunde

- rkB/s: Gelesene KBytes pro Sekunde

- wkB/s: Geschriebene KBytes pro Sekunde

- avgrq-sz: Durchschnittsgröße eines Disk Requests

- avgqu-sz: Durchschnittliche Länge der Request Queue

- await: Durchschnittlicher Zeitbedarf (in ms) für einen Request. Dieser Wert beinhaltet die Wartezeit in der Queue und die Zeit, die die Festplatte benötigt hat.

- svctm: Servicezeit der Festplatte (ohne Wartezeit in der Queue)

- util: Auslastung der CPUs (globaler Durchschnitt)

Dateisystem tunen

Auf aktuellen Linux-Systemen kommen eigentlich nur noch Journal-basierte Dateisysteme zum Einsatz. Hierbei werden die (Meta-)Daten zuerst in ein Journal geschrieben und dann innerhalb des eigentlichen Dateisystems geändert. Dies minimiert die Gefahr eines Datenverlusts bei einem Systemcrash. Standard ist heutzutage ext4, der Nachfolger von ext3 und ext2. Für sehr große Dateien und Partitionsgrößen bietet sich XFS an. Beide Dateisysteme bieten eine Vielzahl von Optionen an, mit denen sich deren Eigenschaften anpassen lassen. Besonders interessant ist hier der Speicherort des Journals. Dieses kann entweder Teil des Dateisystems selbst sein oder an einer anderen Stelle liegen. Um große Seek-Zeiten zu vermeiden, bietet es sich an, das Journal auf eine eigene Platte zu legen. Allerdings ist darauf zu achten, dass diese keine schlechtere Performance als die eigentlichen Daten-Festplatten besitzt, da sich ansonsten der Performance-Gewinn natürlich wieder negieren würde.

Der folgende Befehl legt beispielsweise das Journal für "/dev/sda1" auf der Partition "/dev/sdb1" ab. Die Blockgrößen sollten dabei zwischen den beiden Geräten identisch sein:

mkfs.ext4 -O /dev/sda1 /dev/sdb1

Können Sie auf den Access-Time-Zeitstempel im Inode einer Datei verzichten, bietet es sich an, die jeweilige Datenpartition mit einer entsprechenden Mount-Option zu versehen. Dies bringt gerade bei vielen kleinen Dateien, beispielsweise bei Web-, Mail-, News- und Proxyservern, einen erheblichen Performance-Gewinn:

mount -o noatime /dev/sda1 /var/www/html/

Der Read-Ahead-Cache ist hervorragend dazu geeignet, um eine Anwendung mit Daten aus dem schnellen Page-Cache zu versorgen. Leider ist der Default-Wert mit 128 KByte recht klein eingestellt. Ein guter Anfangswert sind 4.096 Blöcke. Das lässt sich wie folgt ändern:

/sbin/blockdev --setra 4096 /dev/sda

Alternativ stellen Sie den Cache direkt im virtuellen Sys-Dateisystem ein:

echo 2048 > /sys/block/vda/queue/read_ahead_kb

Hier müssen Sie darauf achten, dass die Datei KByte als Eingabewert erwartet. Da ein Block per Default 512 Byte groß ist, müssen Sie den Wert entsprechend anpassen.

Die Größe des Write-Cache manipulieren Sie durch folgende Befehle:

echo 10 > /proc/sys/vm/dirty_ratio

echo 5 > /proc/sys/vm/dirty_background_ratio

Damit erlauben Sie, dass zehn Prozent des RAM für einen einzelnen Prozess als Write-Cache verwendet werden. Wenn fünf Prozent geänderte Daten im Write-Cache liegen, wird der Auslagerungsprozess auf die Festplatte angestoßen. Um die Werte persistent einzustellen, sind die jeweiligen Befehle beispielsweise in der Datei aufzurufen oder in der Datei zu definieren. Letztere eignet sich jedoch nicht für sämtliche Einstellungen.

Um nun den Erfolg der durchgeführten Tuning-Arbeiten zu messen, eignen sich die unter [2] und [3] genannten Benchmark-Tools sehr gut. Mit deren Hilfe lassen sich aus den ermittelten Werten auch aussagekräftige Grafiken erzeugen.

Bild 2: Das vereinfachte OSI-Modell stellt vier Netzwerk-Schichten zur Verfügung, auf denen Optimierungen vorgenommen werden können