🥇Linux-Kernel-Konfiguration für GlusterFS

Die Übersetzung des Artikels wurde im Vorfeld des Starts des Kurses vorbereitet „Administrator Linux. Professionell“.

Es tauchen regelmäßig Fragen zu den Empfehlungen von Gluster bezüglich der Kernelkonfiguration auf und ob diese notwendig sind.

Eine solche Notwendigkeit tritt selten auf. Bei den meisten Arbeitslasten funktioniert der Kernel sehr gut. Es gibt jedoch auch eine Kehrseite. Historisch gesehen verbraucht der Linux-Kernel bereitwillig viel Speicher, wenn man ihm die Möglichkeit dazu gibt, unter anderem für das Caching als primären Weg zur Leistungssteigerung.

In den meisten Fällen funktioniert es hervorragend, kann jedoch bei hoher Auslastung zu Problemen führen.

Wir haben viel Erfahrung mit speicherintensiven Systemen wie CAD, EDA und ähnlichem, die bei hoher Auslastung anfingen, zu ruckeln. Manchmal hatten wir auch Probleme mit Gluster. Nachdem wir mehrere Tage lang den verwendeten Speicher und die Wartezeiten der Festplatten genau beobachtet hatten, erfuhren wir von Überlastungen, enormen iowait, Kernel-Fehlern (Kernel Oops), Hängern usw.

Dieser Artikel ist das Ergebnis vieler Experimente zur Anpassung von Parametern, die in verschiedenen Situationen durchgeführt wurden. Dank dieser Parameter hat sich nicht nur die Reaktionsfähigkeit im Allgemeinen verbessert, sondern auch die Stabilität des Clusters erheblich gesteigert.

Wenn es um die Konfiguration des Speichers geht, sollte man zunächst das virtuelle Speichersystem (VM, virtual memory) betrachten, das viele Optionen bietet, die verwirrend sein können.

vm.swappiness

Parameter vm.swappiness bestimmt, wie stark der Kernel das Swapping im Vergleich zum Arbeitsspeicher nutzt. Im Quellcode ist er auch als „tendency to steal mapped memory“ (Neigung, zugeordneten Speicher zu stehlen) definiert. Ein hoher Swappiness-Wert bedeutet, dass der Kernel eher geneigt ist, zugeordnete Seiten auszulagern. Ein niedriger Wert bedeutet das Gegenteil: Der Kernel wird weniger Seiten aus dem Speicher auslagern. Mit anderen Worten, je höher der Wert vm.swappiness, desto mehr wird das System Swap verwenden.

Ein hohes Maß an Swapping ist unerwünscht, da große Datenblöcke in den Arbeitsspeicher geladen und ausgelagert werden. Viele behaupten, der Swappiness-Wert sollte hoch sein, aber nach meiner Erfahrung führt die Einstellung auf „0“ zu einer Leistungssteigerung.

Weitere Informationen sind hier zu finden – lwn.net/Articles/100978

Diese Einstellungen sollten jedoch mit Vorsicht angewendet werden und nur nach dem Testen der spezifischen Anwendung. Für stark belastete Streaming-Anwendungen sollte dieser Parameter auf „0“ gesetzt werden. Bei der Änderung auf „0“ verbessert sich die Systemreaktionsfähigkeit.

vm.vfs_cache_pressure

Dieser Parameter steuert den vom Kernel verwendeten Speicher zur Zwischenspeicherung von Verzeichnisobjekten und Indexbeschreibungen (dentry und inode).

Bei einem Standardwert von 100 versucht der Kernel, den dentry- und inode-Cache „fair“ im Verhältnis zum pagecache und swapcache freizugeben. Eine Verringerung von vfs_cache_pressure führt dazu, dass der Kernel dentry und inode-Caches beibehält. Wenn der Wert auf „0“ gesetzt ist, wird der Kernel den dentry- und inode-Cache niemals aufgrund von Speichermangel (memory pressure) löschen, was leicht zu einem Out-of-Memory-Fehler führen kann. Eine Erhöhung der vfs_cache_pressure über 100 führt dazu, dass der Kernel die Auslagerung von dentry und inode priorisiert.

Bei der Verwendung von GlusterFS können viele Benutzer mit großen Datenmengen und vielen kleinen Dateien leicht eine erhebliche Menge an RAM auf dem Server aufgrund der Zwischenspeicherung von inode/dentry nutzen, was die Leistung beeinträchtigen kann, da der Kernel gezwungen ist, Datenstrukturen in einem System mit 40 GB RAM zu verarbeiten. Die Einstellung dieses Wertes über 100 hat vielen Benutzern geholfen, eine gerechtere Zwischenspeicherung zu erreichen und die Reaktionsfähigkeit des Kernels zu verbessern.

vm.dirty_background_ratio und vm.dirty_ratio

Der erste Parameter (vm.dirty_background_ratio) bestimmt den Prozentsatz des Speichers mit schmutzigen Seiten, ab dem ein Hintergrund-Flush schmutziger Seiten auf die Festplatte gestartet werden muss. Solange dieser Prozentsatz nicht erreicht ist, werden die Seiten nicht auf die Festplatte geschrieben. Wenn der Flush beginnt, geschieht dies im Hintergrund, ohne die laufenden Prozesse zu unterbrechen.

Der zweite Parameter (vm.dirty_ratio) bestimmt den Prozentsatz des Speichers, der von schmutzigen Seiten verwendet werden kann, bevor ein erzwungener Rücklauf (forced flash) beginnt. Wenn dieser Schwellenwert erreicht ist, werden alle Prozesse synchron (blockiert), und sie dürfen ihre Arbeit nicht fortsetzen, bis der angeforderte Ein-/Ausgabevorgang tatsächlich abgeschlossen ist und die Daten auf der Festplatte vorhanden sind. Bei intensiven Ein-/Ausgabeoperationen verursacht dies Probleme, da das Caching fehlt und alle Prozesse, die Ein-/Ausgaben durchführen, auf die Ein-/Ausgabe warten. Dies führt zu vielen hängenden Prozessen, hoher Last, instabiler Systemleistung und schlechten Leistungswerten.

Eine Verringerung dieser Parameterwerte führt dazu, dass Daten häufiger auf die Festplatte geschrieben werden und nicht im RAM gespeichert bleiben. Dies kann Systemen mit viel Speicher helfen, für die es normal ist, einen Seiten-Cache von 45–90 GB auf die Festplatte zu schreiben, was zu enormen Wartezeiten für Frontend-Anwendungen führt und die Gesamterantwortzeit sowie die Interaktivität verringert.

„1“ > /proc/sys/vm/pagecache

Der Seiten-Cache ist ein Cache, in dem Daten von Dateien und ausführbaren Programmen gespeichert werden, das heißt, es handelt sich um Seiten mit dem tatsächlichen Inhalt von Dateien oder Blockgeräten. Dieser Cache wird verwendet, um die Anzahl der Lesevorgänge von der Festplatte zu reduzieren. Ein Wert von „1“ bedeutet, dass 1 % des RAMs für den Cache verwendet werden und es mehr Lesevorgänge von der Festplatte als aus dem RAM geben wird. Es ist nicht erforderlich, diesen Parameter zu ändern, aber wenn Sie paranoid bezüglich der Kontrolle über den Seiten-Cache sind, können Sie ihn anpassen.

„deadline“ > /sys/block/sdc/queue/scheduler

Der I/O-Scheduler ist ein Kernkomponente von Linux, die Lese- und Schreibwarteschlangen verwaltet. Theoretisch ist es für einen intelligenten RAID-Controller besser, „noop“ zu verwenden, da Linux nichts über die physische Geometrie der Festplatte weiß. Daher ist es effizienter, dem Controller, der die Geometrie der Festplatte gut kennt, zu ermöglichen, die Anfrage so schnell wie möglich zu bearbeiten. Es scheint jedoch, dass „deadline“ die Leistung verbessert. Weitere Details zu den Planern finden Sie in der Dokumentation zum Quellcode des Linux-Kernels: linux/Documentation/block/*osched.txt. Außerdem habe ich einen Anstieg der Leseleistung bei gemischten Operationen (viele Schreibvorgänge) beobachtet.

„256“ > /sys/block/sdc/queue/nr_requests

Die Anzahl der Ein- und Ausgabeforderungen im Puffer, bevor sie an den Scheduler übergeben werden. Die Größe der internen Warteschlange einiger Controller (queue_depth) ist größer als nr_requests des I/O-Schedulers, sodass der I/O-Scheduler kaum in der Lage ist, die Anfragen richtig zu priorisieren und zusammenzuführen. Für die Scheduler Deadline und CFQ ist es besser, wenn nr_requests doppelt so groß ist wie die interne Warteschlange des Controllers. Das Zusammenführen und Umordnen von Anfragen hilft dem Scheduler, unter hoher Last reaktionsschneller zu sein.

echo «16» > /proc/sys/vm/page-cluster

Der Parameter page-cluster steuert die Anzahl der Seiten, die auf einmal in den Swap geschrieben werden. Im obigen Beispiel wird der Wert auf „16“ gesetzt, entsprechend der Stripe-Größe (stripe size) von RAID mit 64 KB. Das macht keinen Sinn bei swappiness = 0, aber wenn Sie swappiness auf 10 oder 20 gesetzt haben, wird Ihnen dieser Wert helfen, wenn die Stripe-Größe von RAID 64 KB beträgt.

blockdev —setra 4096 /dev/`<`devname`>` (-sdb, hdc oder dev_mapper)

Die Standardeinstellungen für Blockgeräte vieler RAID-Controller führen oft zu einer katastrophalen Leistung. Das Hinzufügen der oben genannten Option konfiguriert das vorzeitige Lesen für 4096 * 512-Byte-Sektoren. Zumindest bei Streaming-Operationen erhöht sich die Geschwindigkeit, indem der integrierte Cache der Festplatte durch vorzeitiges Lesen während des Zeitraums gefüllt wird, den der Kernel zur Vorbereitung von I/O nutzt. Daten, die bei der nächsten Leseanfrage angefordert werden, können im Cache abgelegt werden. Ein zu großes vorzeitiges Lesen kann den zufälligen I/O für große Dateien beeinträchtigen, wenn es potenziell nützliche Disk-Zeit nutzt oder Daten außerhalb des Caches lädt.

Hier sind einige weitere Empfehlungen auf Dateisystemebene. Diese wurden jedoch noch nicht getestet. Stellen Sie sicher, dass Ihr Dateisystem die Größe des Stripes und die Anzahl der Festplatten im Array kennt. Zum Beispiel, dass es sich um ein RAID5-Array mit einer Stripe-Größe von 64K aus sechs Festplatten handelt (tatsächlich aus fünf, da eine Festplatte für die Parität verwendet wird). Diese Empfehlungen basieren auf theoretischen Annahmen und stammen aus verschiedenen Blogs/Artikeln von RAID-Experten.

-> ext4 fs, 5 Festplatten, 64K Stripe, Einheiten in 4K Blöcken
mkfs -text4 -E stride=$((64/4))
-> xfs, 5 Festplatten, 64K Stripe, Einheiten in 512-Byte-Sektoren
mkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))

Für große Dateien kann man in Betracht ziehen, die oben angegebenen Stripe-Größen zu erhöhen.

ACHTUNG! Alles, was oben beschrieben ist, ist für einige Anwendungsarten extrem subjektiv. Dieser Artikel garantiert keine Verbesserungen ohne vorheriges Testen der entsprechenden Anwendungen durch den Benutzer. Er sollte nur angewendet werden, wenn es notwendig ist, die allgemeine Systemreaktionsfähigkeit zu verbessern oder wenn er aktuelle Probleme löst.