Der Artikel wurde im Vorfeld des Kurses erstellt .
Immer wieder treten Fragen zu den Empfehlungen von Gluster bezüglich der Kernelkonfiguration auf und ob dies notwendig ist.
So eine Notwendigkeit tritt selten auf. In den meisten Anwendungen arbeitet der Kernel sehr gut. Allerdings gibt es auch die Kehrseite. Historisch gesehen verbraucht der Linux-Kernel viel Speicher, wenn ihm dies ermöglicht wird, insbesondere für das Caching als primäre Methode zur Leistungssteigerung.
In den meisten Fällen funktioniert das ausgezeichnet, kann jedoch bei hoher Last zu Problemen führen.
Wir haben umfassende Erfahrung mit speicherintensiven Systemen wie CAD, EDA und ähnlichen Anwendungen, die bei hoher Belastung anfingen zu stocken. Manchmal hatten wir auch Probleme mit Gluster. Durch sorgfältige Beobachtungen über längere Zeit hinsichtlich des genutzten Speichers und der Wartezeiten der Festplatten haben wir deren Überlastung, enorme iowait-Werte, Kernel-Fehler (kernel oops), Hänger usw. festgestellt.
Dieser Artikel ist das Ergebnis zahlreicher Experimente zur Optimierung von Einstellungen, die unter verschiedenen Bedingungen durchgeführt wurden. Diese Parameter haben nicht nur die allgemeine Reaktionsfähigkeit verbessert, sondern auch die Stabilität des Clusters erheblich erhöht.
Wenn es um die Anpassung des Arbeitsspeichers geht, sollte man zunächst die virtuelle Speicherverwaltung (VM, virtual memory) betrachten, die viele Optionen bietet und verwirrend sein kann.
vm.swappiness
Parameter vm.swappiness bestimmt, inwieweit der Kernel Swapping im Vergleich zum Arbeitsspeicher nutzt. Im Quellcode ist er auch als "tendency to steal mapped memory" (Neigung, zugewiesenen Speicher zu stehlen) definiert. Ein hoher Swappiness-Wert bedeutet, dass der Kernel eher geneigt ist, zugewiesene Seiten auszulagern. Ein niedriger Swappiness-Wert bedeutet das Gegenteil: der Kernel lagert weniger Seiten aus dem Arbeitsspeicher aus. Mit anderen Worten, je höher der Wert vm.swappiness, desto mehr wird das System Swap verwenden.
Eine hohe Nutzung von Swapping sollte vermieden werden, da große Datenblöcke in den Arbeitsspeicher geladen und daraus entfernt werden. Viele behaupten, dass der Wert für die Swappiness hoch sein sollte, aber meiner Erfahrung nach führt eine Einstellung auf „0“ zu einer Leistungssteigerung.
Weitere Informationen finden Sie hier —
Diese Einstellungen sollten jedoch mit Vorsicht angewendet und nur nach dem Testen der spezifischen Anwendung vorgenommen werden. Für stark belastete Streaming-Anwendungen sollte dieser Parameter auf „0“ gesetzt werden. Bei der Änderung auf „0“ verbessert sich die Reaktionsfähigkeit des Systems.
vm.vfs_cache_pressure
Dieser Parameter steuert den Speicher, den der Kernel für das Caching von Verzeichnisobjekten und Indexbezeichnern (dentry und inode) benötigt.
Bei einem Standardwert von 100 wird der Kernel versuchen, die dentry- und inode-Caches nach "Fairness" im Verhältnis zum Page-Cache und Swap-Cache freizugeben. Eine Verringerung der vfs_cache_pressure führt dazu, dass der Kernel die dentry- und inode-Caches speichert. Wenn der Wert "0" ist, wird der Kernel die dentry- und inode-Caches wegen Speicherknappheit (memory pressure) niemals leeren, was leicht zu einem Out-of-Memory-Fehler führen kann. Eine Erhöhung der vfs_cache_pressure über 100 priorisiert die Entladung von dentry und inode.
Bei der Verwendung von GlusterFS können viele Benutzer mit großen Datenmengen und zahlreichen kleinen Dateien auf dem Server beträchtliche Mengen an RAM aufgrund der dentry/inode-Caching verwenden, was zu einer geringeren Leistung führen kann, da der Kernel gezwungen ist, Datenstrukturen in einem System mit 40 GB RAM zu verarbeiten. Das Setzen dieses Parameters auf über 100 hat vielen Benutzern geholfen, ein faireres Caching zu erreichen und die Reaktionsfähigkeit des Kernels zu verbessern.
vm.dirty_background_ratio und vm.dirty_ratio
Erster Parameter (vm.dirty_background_ratio) definiert den Prozentsatz des Speichers mit schmutzigen Seiten, bei dem ein Hintergrund-Flush der schmutzigen Seiten auf die Festplatte gestartet werden muss. Solange dieser Prozentsatz nicht erreicht ist, werden die Seiten nicht auf die Festplatte geschrieben. Wenn der Flush jedoch startet, erfolgt dies im Hintergrund, ohne laufende Prozesse zu unterbrechen.
Der zweite Parameter (vm.dirty_ratio) bestimmt den Prozentsatz des Speichers, der von schmutzigen Seiten belegt sein kann, bevor ein erzwungener Flush (forced flash) beginnt. Wenn dieser Schwellenwert erreicht wird, werden alle Prozesse synchronisiert (blockiert) und dürfen nicht weiterarbeiten, bis die angeforderte Ein-/Ausgabe-Operation tatsächlich abgeschlossen ist und die Daten auf der Festplatte sind. Bei stark belastetem Ein-/Ausgabeverkehr führt dies zu Problemen, da eine Daten-Caching nicht erfolgt und alle Prozesse, die Ein-/Ausgaben durchführen, auf die Ein-/Ausgabe warten und blockiert werden. Dies führt zu einer hohen Anzahl von hängenden Prozessen, hoher Auslastung, instabiler Systemleistung und schlechter Performance.
Die Reduzierung dieser Parameterwerte führt dazu, dass Daten häufiger auf die Festplatte geschrieben werden und nicht im RAM gespeichert werden. Dies kann Systemen mit viel RAM helfen, bei denen es normal ist, den Seitencache von 45–90 GB auf die Festplatte abzulegen, was zu enormen Wartezeiten für Frontend-Anwendungen führt und die allgemeine Reaktionsfähigkeit und Interaktivität verringert.
«1» > /proc/sys/vm/pagecache
Der Seitencache (page cache) ist ein Cache, der die Daten von Dateien und ausführbaren Programmen speichert, also 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. Der Wert „1“ bedeutet, dass 1 % des RAM für den Cache verwendet wird und die Lesevorgänge von der Festplatte höher sein werden als die aus dem RAM. Es ist nicht unbedingt erforderlich, diesen Parameter zu ändern, aber wenn Sie paranoid bezüglich der Kontrolle über den Seitencache sind, können Sie dies tun.
«deadline» > /sys/block/sdc/queue/scheduler
Der I/O-Scheduler ist ein Bestandteil des Linux-Kernels, der Lese- und Schreibanfragen verwaltet. Theoretisch wäre es besser, für einen intelligenten RAID-Controller den „noop“-Scheduler zu verwenden, da Linux nichts über die physische Geometrie der Festplatte weiß. Es ist daher effizienter, den Controller, der die Geometrie kennt, die Anfragen so schnell wie möglich bearbeiten zu lassen. Es scheint jedoch, dass der „deadline“-Scheduler die Leistung steigert. Mehr Informationen zu den Scheduler finden Sie in der Dokumentation des Linux-Kernel-Codes: linux/Documentation/block/*osched.txt. Ich habe auch einen Anstieg der Leseleistung bei gemischten Operationen (viele Schreiboperationen) festgestellt.
«256» > /sys/block/sdc/queue/nr_requests
Die Anzahl der E/A-Anfragen 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 E/A-Schedulers, wodurch es dem Scheduler schwerfällt, Anfragen korrekt 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 Zusammenfassen und Umordnen von Anfragen hilft dem Scheduler, bei hoher Auslastung reaktionsschneller zu sein.
echo «16» > /proc/sys/vm/page-cluster
Der Parameter page-cluster verwaltet die Anzahl der Seiten, die auf einmal in den Swap geschrieben werden. Im obigen Beispiel wird der Wert auf «16» festgelegt, entsprechend der Stripe-Größe des RAID von 64 KB. Das ist bei swappiness = 0 nicht sinnvoll, aber wenn Sie swappiness auf 10 oder 20 gesetzt haben, hilft Ihnen dieser Wert, wenn die Stripe-Größe des RAID 64 KB beträgt.
blockdev —setra 4096 /dev/<devname> (-sdb, hdc oder dev_mapper)
Die standardmäßigen Blockgeräteinstellungen vieler RAID-Controller führen oft zu katastrophaler Leistung. Durch die Hinzufügung der oben genannten Option wird das vorzeitige Lesen für 4096 * 512-Byte-Sektoren konfiguriert. Dies erhöht zumindest bei Streaming-Operationen die Geschwindigkeit, indem der integrierte Speicher des Laufwerks durch vorzeitiges Lesen während des Zeitraums gefüllt wird, den der Kernel für die Vorbereitung der Ein- und Ausgaben benötigt. Im Cache können Daten abgelegt werden, die bei der nächsten Leseoperation angefordert werden. Zu viel vorzeitiges Lesen kann jedoch die zufälligen Ein- und Ausgaben bei großen Dateien beeinträchtigen, wenn es potenziell nützliche Zeit des Laufwerks verwendet oder Daten außerhalb des Caches lädt.
Hier sind einige zusätzliche Empfehlungen auf Ebene des Dateisystems. 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 handelt es sich um ein Raid5-Array mit einer Stripe-Größe von 64K aus sechs Festplatten (tatsächlich fünf, da eine Festplatte für Parität verwendet wird). Diese Empfehlungen basieren auf theoretischen Annahmen und wurden aus verschiedenen Blogs und Artikeln von RAID-Experten zusammengestellt.
-> 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 könnte es sinnvoll sein, die oben genannten Stripe-Größen zu erhöhen.
ACHTUNG! Alles, was oben beschrieben wurde, ist für einige Anwendungstypen extrem subjektiv. Dieser Artikel garantiert keine Verbesserungen ohne vorherige Tests der entsprechenden Anwendungen durch den Benutzer. Er sollte nur angewendet werden, wenn eine Verbesserung der allgemeinen Systemreaktionsfähigkeit erforderlich ist oder wenn er aktuelle Probleme löst.
Zusätzliche Materialien:
Mehr lesen
Quelle: habr.com
