Die Übersetzung des Artikels wurde am Vorabend des Kursbeginns erstellt .
Von Zeit zu Zeit tauchen Fragen zu den Empfehlungen von Gluster zum Kernel-Tuning auf und ob ein Bedarf dafür besteht.
Ein solcher Bedarf entsteht selten. Bei den meisten Arbeitslasten schneidet der Kernel sehr gut ab. Obwohl es einen Nachteil gibt. In der Vergangenheit war der Linux-Kernel bereit, viel Speicher zu verbrauchen, wenn er die Möglichkeit dazu hatte, auch für Caching als wichtigste Möglichkeit zur Leistungsverbesserung.
In den meisten Fällen klappt das einwandfrei, bei starker Belastung kann es jedoch zu Problemen kommen.
Wir haben viel Erfahrung mit speicherintensiven Systemen wie CAD, EDA und dergleichen, die bei starker Auslastung langsamer wurden. Und manchmal hatten wir in Gluster Probleme. Nachdem wir die Speichernutzung und die Festplattenlatenz viele Tage lang sorgfältig beobachtet hatten, stellten wir fest, dass es zu Überlastung, großem Iowait, Kernel-Fehlern (Kernel-Ups), Einfrierungen usw. kam.
Dieser Artikel ist das Ergebnis vieler Tuning-Experimente, die in verschiedenen Situationen durchgeführt wurden. Dank dieser Parameter hat sich nicht nur die allgemeine Reaktionsfähigkeit verbessert, sondern auch der Cluster hat sich deutlich stabilisiert.
Wenn es um die Speicheroptimierung geht, sollten Sie sich zunächst das virtuelle Speichersubsystem (VM, virtueller Speicher) ansehen, das über eine große Anzahl von Optionen verfügt, die Sie verwirren können.
vm.swappiness
Parameter vm.swappiness bestimmt, wie viel der Kernel Swap (Swap, Paging) im Vergleich zum RAM verwendet. Im Quellcode wird es auch als „Tendenz, zugeordneten Speicher zu stehlen“ definiert. Eine hohe Swappiness bedeutet, dass der Kernel eher dazu neigt, zugeordnete Seiten auszutauschen. Ein niedriger Swappiness-Wert bedeutet das Gegenteil: Der Kernel lagert weniger aus dem Speicher. Mit anderen Worten: Je höher der Wert vm.swappiness, desto häufiger verwendet das System Swap.
Ein umfangreicher Einsatz von Swapping ist unerwünscht, da große Datenblöcke in den RAM geladen und entladen werden. Viele Leute argumentieren, dass der Swapiness-Wert groß sein sollte, aber meiner Erfahrung nach führt die Einstellung auf „0“ zu einer besseren Leistung.
Mehr können Sie hier lesen -
Aber auch diese Einstellungen sollten mit Vorsicht und nur nach dem Testen einer bestimmten Anwendung angewendet werden. Für stark ausgelastete Streaming-Anwendungen sollte dieser Parameter auf „0“ gesetzt werden. Bei Änderung auf „0“ verbessert sich die Reaktionsfähigkeit des Systems.
vm.vfs_cache_pression
Diese Einstellung steuert den Speicher, der vom Kernel zum Zwischenspeichern von Verzeichnis- und Inode-Objekten (dentry und inode) verbraucht wird.
Bei einem Standardwert von 100 versucht der Kernel, die Dentry- und Inode-Caches auf „fairer“ Basis für Pagecache und Swapcache freizugeben. Durch Verringern von vfs_cache_pression behält der Kernel Dentry- und Inode-Caches bei. Wenn der Wert „0“ ist, wird der Kernel aufgrund von Speicherdruck niemals den Dentry- und Inode-Cache leeren, was leicht zu einem Fehler wegen unzureichendem Speicher führen kann. Wenn vfs_cache_pression auf über 100 erhöht wird, priorisiert der Kernel das Dentry- und Inode-Flushing.
Bei der Verwendung von GlusterFS können viele Benutzer mit großen Datenmengen und vielen kleinen Dateien aufgrund des Inode-/Dentry-Cachings leicht eine erhebliche Menge RAM auf dem Server nutzen, was zu Leistungseinbußen führen kann, da der Kernel Datenstrukturen auf einem System verarbeiten muss mit 40 GB Speicher. Das Festlegen dieses Werts über 100 hat vielen Benutzern geholfen, ein gerechteres Caching und eine verbesserte Kernel-Reaktionsfähigkeit zu erreichen.
vm.dirty_background_ratio und vm.dirty_ratio
Erster Parameter (vm.dirty_background_ratio) bestimmt den Prozentsatz des Speichers mit schmutzigen Seiten, nach dessen Erreichen es notwendig ist, schmutzige Seiten im Hintergrund auf die Festplatte zu leeren. Bis dieser Prozentsatz erreicht ist, werden keine Seiten auf die Festplatte geschrieben. Und wenn ein Reset startet, läuft er im Hintergrund, ohne laufende Prozesse zu unterbrechen.
Der zweite Parameter (vm.dirty_ratio) definiert den Prozentsatz des Speichers, der von fehlerhaften Seiten belegt werden kann, bevor der erzwungene Flash beginnt. Sobald dieser Schwellenwert erreicht ist, werden alle Prozesse synchron (blockiert) und dürfen nicht fortgesetzt werden, bis die von ihnen angeforderte E/A tatsächlich abgeschlossen ist und die Daten auf der Festplatte sind. Bei starken I/O-Vorgängen stellt dies ein Problem dar, da kein Daten-Caching stattfindet und alle Prozesse, die I/O-Vorgänge ausführen, blockiert sind und auf I/O-Vorgänge warten. Dies führt zu einer großen Anzahl blockierter Prozesse, hoher Auslastung, Systeminstabilität und schlechter Leistung.
Das Verringern dieser Einstellungen führt dazu, dass Daten häufiger auf die Festplatte geschrieben und nicht im RAM gespeichert werden. Dies kann speicherintensiven Systemen helfen, bei denen normalerweise 45–90 GB Seitencaches auf die Festplatte geleert werden, was zu einer enormen Latenz für Front-End-Anwendungen führt und die allgemeine Reaktionsfähigkeit und Interaktivität verringert.
„1“ > /proc/sys/vm/pagecache
Ein Seitencache 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 Festplattenlesevorgänge zu reduzieren. Ein Wert von „1“ bedeutet, dass 1 % des RAM für den Cache verwendet wird und mehr Lesevorgänge von der Festplatte als vom RAM erfolgen. Es ist nicht notwendig, diese Einstellung zu ändern, aber wenn Sie Angst vor der Kontrolle des Seitencaches haben, können Sie sie verwenden.
„Deadline“ > /sys/block/sdc/queue/scheduler
Der I/O-Scheduler ist eine Linux-Kernel-Komponente, die Lese- und Schreibwarteschlangen verwaltet. Theoretisch ist es besser, „noop“ für einen intelligenten RAID-Controller zu verwenden, da Linux nichts über die physische Geometrie der Festplatte weiß. Daher ist es effizienter, den Controller, der die Festplattengeometrie gut kennt, die Anfrage so schnell wie möglich verarbeiten zu lassen möglich. Aber es sieht so aus, als ob „Deadline“ die Leistung verbessert. Weitere Informationen zu Schedulern finden Sie in der Dokumentation zum Linux-Kernel-Quellcode: linux/Documentation/block/*osched.txt. Außerdem habe ich bei gemischten Vorgängen (viele Schreibvorgänge) einen Anstieg des Lesedurchsatzes festgestellt.
„256“ > /sys/block/sdc/queue/nr_requests
Die Anzahl der E/A-Anfragen im Puffer, bevor sie an den Scheduler übergeben werden. Die interne Warteschlangengröße (Queue_Tiefe) einiger Controller ist größer als die nr_requests des I/O-Schedulers, sodass der I/O-Scheduler kaum eine Chance hat, Anforderungen richtig zu priorisieren und zusammenzuführen. Für Deadline- und CFQ-Scheduler ist es besser, wenn nr_requests das Zweifache der internen Warteschlange des Controllers beträgt. Durch das Zusammenführen und Neuordnen von Anforderungen kann der Planer bei hoher Auslastung schneller reagieren.
echo „16“ > /proc/sys/vm/page-cluster
Der Parameter page-cluster steuert die Anzahl der Seiten, die gleichzeitig in den Swap geschrieben werden. Im obigen Beispiel ist der Wert entsprechend der RAID-Stripe-Größe von 16 KB auf „64“ gesetzt. Mit swappiness = 0 macht es keinen Sinn, aber wenn Sie swappiness auf 10 oder 20 setzen, hilft Ihnen die Verwendung dieses Werts, wenn die RAID-Stripe-Größe 64 KB beträgt.
blockdev --setra 4096 /dev/<Entwicklername> (-sdb, hdc oder dev_mapper)
Die Standardeinstellungen für Blockgeräte führen bei vielen RAID-Controllern häufig zu einer schlechten Leistung. Durch Hinzufügen der oben genannten Option wird das Vorauslesen für 4096 * 512-Byte-Sektoren eingerichtet. Zumindest bei Streaming-Vorgängen wird die Geschwindigkeit erhöht, indem der On-Chip-Festplatten-Cache während des Zeitraums, den der Kernel zur Vorbereitung der E/A verwendet, mit Read-Ahead gefüllt wird. Der Cache kann Daten enthalten, die beim nächsten Lesevorgang angefordert werden. Zu viel Prefetch kann zufällige I/O-Operationen für große Dateien zerstören, wenn es potenziell nützliche Festplattenzeit verbraucht oder Daten außerhalb des Caches lädt.
Nachfolgend finden Sie einige weitere Empfehlungen auf Dateisystemebene. Aber sie wurden noch nicht getestet. Stellen Sie sicher, dass Ihr Dateisystem die Größe des Stripes und die Anzahl der Festplatten im Array kennt. Beispielsweise handelt es sich um ein 5-KByte-Stripe-RAID64-Array mit sechs Festplatten (eigentlich fünf, da eine Festplatte für die Parität verwendet wird). Diese Empfehlungen basieren auf theoretischen Annahmen und wurden aus verschiedenen Blogs/Artikeln von RAID-Experten zusammengestellt.
-> ext4 fs, 5 disks, 64K stripe, units in 4K blocks
mkfs -text4 -E stride=$((64/4))
-> xfs, 5 disks, 64K stripe, units in 512-byte sectors
mkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))Erwägen Sie bei großen Dateien, die oben aufgeführten Stripe-Größen zu erhöhen.
WARNUNG! Alles, was oben beschrieben wurde, ist für einige Arten von Anwendungen sehr subjektiv. Dieser Artikel garantiert keine Verbesserungen ohne vorherige Benutzertests verwandter Anwendungen. Es sollte nur verwendet werden, wenn es notwendig ist, die allgemeine Reaktionsfähigkeit des Systems zu verbessern, oder wenn es aktuelle Probleme löst.
Zusätzliche Materialien:
Weiterlesen
Source: habr.com