{"id":95783,"date":"2020-10-03T13:42:02","date_gmt":"2020-10-03T11:42:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/nastrojka-yadra-linux-dlya-glusterfs"},"modified":"2020-10-03T13:42:02","modified_gmt":"2020-10-03T11:42:02","slug":"nastrojka-yadra-linux-dlya-glusterfs","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/nastrojka-yadra-linux-dlya-glusterfs","title":{"rendered":"Konfiguration des Linux-Kernels f\u00fcr GlusterFS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Der Artikel wurde im Vorfeld des Kurses erstellt \u00abLinux-Administrator. Professionell\u00bb<\/a><\/noindex>.<\/i><\/b><\/p>\n

\"Konfiguration<\/p>\n

Immer wieder treten Fragen zu den Empfehlungen von Gluster bez\u00fcglich der Kernelkonfiguration auf und ob dies notwendig ist.<\/p>\n

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\u00f6glicht wird, insbesondere f\u00fcr das Caching als prim\u00e4re Methode zur Leistungssteigerung.<\/a><\/noindex><\/p>\n

In den meisten F\u00e4llen funktioniert das ausgezeichnet, kann jedoch bei hoher Last zu Problemen f\u00fchren. <\/p>\n

Wir haben umfassende Erfahrung mit speicherintensiven Systemen wie CAD, EDA und \u00e4hnlichen Anwendungen, die bei hoher Belastung anfingen zu stocken. Manchmal hatten wir auch Probleme mit Gluster. Durch sorgf\u00e4ltige Beobachtungen \u00fcber l\u00e4ngere Zeit hinsichtlich des genutzten Speichers und der Wartezeiten der Festplatten haben wir deren \u00dcberlastung, enorme iowait-Werte, Kernel-Fehler (kernel oops), H\u00e4nger usw. festgestellt. <\/p>\n

Dieser Artikel ist das Ergebnis zahlreicher Experimente zur Optimierung von Einstellungen, die unter verschiedenen Bedingungen durchgef\u00fchrt wurden. Diese Parameter haben nicht nur die allgemeine Reaktionsf\u00e4higkeit verbessert, sondern auch die Stabilit\u00e4t des Clusters erheblich erh\u00f6ht.<\/p>\n

Wenn es um die Anpassung des Arbeitsspeichers geht, sollte man zun\u00e4chst die virtuelle Speicherverwaltung (VM, virtual memory) betrachten, die viele Optionen bietet und verwirrend sein kann.<\/p>\n

vm.swappiness<\/h4>\n

\nParameter vm.swappiness<\/code> 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\u00f6her der Wert vm.swappiness<\/code>, desto mehr wird das System Swap verwenden.<\/p>\n

Eine hohe Nutzung von Swapping sollte vermieden werden, da gro\u00dfe Datenbl\u00f6cke in den Arbeitsspeicher geladen und daraus entfernt werden. Viele behaupten, dass der Wert f\u00fcr die Swappiness hoch sein sollte, aber meiner Erfahrung nach f\u00fchrt eine Einstellung auf \u201e0\u201c zu einer Leistungssteigerung.<\/p>\n

Weitere Informationen finden Sie hier \u2014 lwn.net\/Articles\/100978<\/a><\/noindex> <\/p>\n

Diese Einstellungen sollten jedoch mit Vorsicht angewendet und nur nach dem Testen der spezifischen Anwendung vorgenommen werden. F\u00fcr stark belastete Streaming-Anwendungen sollte dieser Parameter auf \u201e0\u201c gesetzt werden. Bei der \u00c4nderung auf \u201e0\u201c verbessert sich die Reaktionsf\u00e4higkeit des Systems.<\/p>\n

vm.vfs_cache_pressure<\/h4>\n

\nDieser Parameter steuert den Speicher, den der Kernel f\u00fcr das Caching von Verzeichnisobjekten und Indexbezeichnern (dentry und inode) ben\u00f6tigt.<\/p>\n

Bei einem Standardwert von 100 wird der Kernel versuchen, die dentry- und inode-Caches nach \"Fairness\" im Verh\u00e4ltnis zum Page-Cache und Swap-Cache freizugeben. Eine Verringerung der vfs_cache_pressure f\u00fchrt 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\u00fchren kann. Eine Erh\u00f6hung der vfs_cache_pressure \u00fcber 100 priorisiert die Entladung von dentry und inode.<\/p>\n

Bei der Verwendung von GlusterFS k\u00f6nnen viele Benutzer mit gro\u00dfen Datenmengen und zahlreichen kleinen Dateien auf dem Server betr\u00e4chtliche Mengen an RAM aufgrund der dentry\/inode-Caching verwenden, was zu einer geringeren Leistung f\u00fchren kann, da der Kernel gezwungen ist, Datenstrukturen in einem System mit 40 GB RAM zu verarbeiten. Das Setzen dieses Parameters auf \u00fcber 100 hat vielen Benutzern geholfen, ein faireres Caching zu erreichen und die Reaktionsf\u00e4higkeit des Kernels zu verbessern.<\/p>\n

vm.dirty_background_ratio und vm.dirty_ratio<\/h4>\n

\nErster Parameter (vm.dirty_background_ratio<\/code>) 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. <\/p>\n

Der zweite Parameter (vm.dirty_ratio<\/code>) 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\u00fcrfen nicht weiterarbeiten, bis die angeforderte Ein-\/Ausgabe-Operation tats\u00e4chlich abgeschlossen ist und die Daten auf der Festplatte sind. Bei stark belastetem Ein-\/Ausgabeverkehr f\u00fchrt dies zu Problemen, da eine Daten-Caching nicht erfolgt und alle Prozesse, die Ein-\/Ausgaben durchf\u00fchren, auf die Ein-\/Ausgabe warten und blockiert werden. Dies f\u00fchrt zu einer hohen Anzahl von h\u00e4ngenden Prozessen, hoher Auslastung, instabiler Systemleistung und schlechter Performance.<\/p>\n

Die Reduzierung dieser Parameterwerte f\u00fchrt dazu, dass Daten h\u00e4ufiger 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\u201390 GB auf die Festplatte abzulegen, was zu enormen Wartezeiten f\u00fcr Frontend-Anwendungen f\u00fchrt und die allgemeine Reaktionsf\u00e4higkeit und Interaktivit\u00e4t verringert.<\/p>\n

\u00ab1\u00bb > \/proc\/sys\/vm\/pagecache<\/h4>\n

\nDer Seitencache (page cache) ist ein Cache, der die Daten von Dateien und ausf\u00fchrbaren Programmen speichert, also Seiten mit dem tats\u00e4chlichen Inhalt von Dateien oder Blockger\u00e4ten. Dieser Cache wird verwendet, um die Anzahl der Lesevorg\u00e4nge von der Festplatte zu reduzieren. Der Wert \u201e1\u201c bedeutet, dass 1 % des RAM f\u00fcr den Cache verwendet wird und die Lesevorg\u00e4nge von der Festplatte h\u00f6her sein werden als die aus dem RAM. Es ist nicht unbedingt erforderlich, diesen Parameter zu \u00e4ndern, aber wenn Sie paranoid bez\u00fcglich der Kontrolle \u00fcber den Seitencache sind, k\u00f6nnen Sie dies tun.<\/p>\n

\u00abdeadline\u00bb > \/sys\/block\/sdc\/queue\/scheduler<\/h4>\n

\nDer I\/O-Scheduler ist ein Bestandteil des Linux-Kernels, der Lese- und Schreibanfragen verwaltet. Theoretisch w\u00e4re es besser, f\u00fcr einen intelligenten RAID-Controller den \u201enoop\u201c-Scheduler zu verwenden, da Linux nichts \u00fcber die physische Geometrie der Festplatte wei\u00df. Es ist daher effizienter, den Controller, der die Geometrie kennt, die Anfragen so schnell wie m\u00f6glich bearbeiten zu lassen. Es scheint jedoch, dass der \u201edeadline\u201c-Scheduler die Leistung steigert. Mehr Informationen zu den Scheduler finden Sie in der Dokumentation des Linux-Kernel-Codes: linux\/Documentation\/block\/*osched.txt<\/code>. Ich habe auch einen Anstieg der Leseleistung bei gemischten Operationen (viele Schreiboperationen) festgestellt.<\/p>\n

\u00ab256\u00bb > \/sys\/block\/sdc\/queue\/nr_requests<\/h4>\n

\nDie Anzahl der E\/A-Anfragen im Puffer, bevor sie an den Scheduler \u00fcbergeben werden. Die Gr\u00f6\u00dfe der internen Warteschlange einiger Controller (queue_depth) ist gr\u00f6\u00dfer als nr_requests des E\/A-Schedulers, wodurch es dem Scheduler schwerf\u00e4llt, Anfragen korrekt zu priorisieren und zusammenzuf\u00fchren. F\u00fcr die Scheduler deadline und CFQ ist es besser, wenn nr_requests doppelt so gro\u00df ist wie die interne Warteschlange des Controllers. Das Zusammenfassen und Umordnen von Anfragen hilft dem Scheduler, bei hoher Auslastung reaktionsschneller zu sein.<\/p>\n

echo \u00ab16\u00bb > \/proc\/sys\/vm\/page-cluster<\/h4>\n

\nDer Parameter page-cluster verwaltet die Anzahl der Seiten, die auf einmal in den Swap geschrieben werden. Im obigen Beispiel wird der Wert auf \u00ab16\u00bb festgelegt, entsprechend der Stripe-Gr\u00f6\u00dfe 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\u00f6\u00dfe des RAID 64 KB betr\u00e4gt.<\/p>\n

blockdev —setra 4096 \/dev\/<<\/code>devname><\/code> (-sdb, hdc oder dev_mapper)<\/h4>\n

\nDie standardm\u00e4\u00dfigen Blockger\u00e4teinstellungen vieler RAID-Controller f\u00fchren oft zu katastrophaler Leistung. Durch die Hinzuf\u00fcgung der oben genannten Option wird das vorzeitige Lesen f\u00fcr 4096 * 512-Byte-Sektoren konfiguriert. Dies erh\u00f6ht zumindest bei Streaming-Operationen die Geschwindigkeit, indem der integrierte Speicher des Laufwerks durch vorzeitiges Lesen w\u00e4hrend des Zeitraums gef\u00fcllt wird, den der Kernel f\u00fcr die Vorbereitung der Ein- und Ausgaben ben\u00f6tigt. Im Cache k\u00f6nnen Daten abgelegt werden, die bei der n\u00e4chsten Leseoperation angefordert werden. Zu viel vorzeitiges Lesen kann jedoch die zuf\u00e4lligen Ein- und Ausgaben bei gro\u00dfen Dateien beeintr\u00e4chtigen, wenn es potenziell n\u00fctzliche Zeit des Laufwerks verwendet oder Daten au\u00dferhalb des Caches l\u00e4dt.<\/p>\n

Hier sind einige zus\u00e4tzliche Empfehlungen auf Ebene des Dateisystems. Diese wurden jedoch noch nicht getestet. Stellen Sie sicher, dass Ihr Dateisystem die Gr\u00f6\u00dfe des Stripes und die Anzahl der Festplatten im Array kennt. Zum Beispiel handelt es sich um ein Raid5-Array mit einer Stripe-Gr\u00f6\u00dfe von 64K aus sechs Festplatten (tats\u00e4chlich f\u00fcnf, da eine Festplatte f\u00fcr Parit\u00e4t verwendet wird). Diese Empfehlungen basieren auf theoretischen Annahmen und wurden aus verschiedenen Blogs und Artikeln von RAID-Experten zusammengestellt.<\/p>\n

-> ext4 fs, 5 Festplatten, 64K Stripe, Einheiten in 4K Bl\u00f6cken\nmkfs -text4 -E stride=$((64\/4))\n-> xfs, 5 Festplatten, 64K Stripe, Einheiten in 512-Byte-Sektoren\nmkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))<\/code><\/pre>\n
\nF\u00fcr gro\u00dfe Dateien k\u00f6nnte es sinnvoll sein, die oben genannten Stripe-Gr\u00f6\u00dfen zu erh\u00f6hen.<\/p>\n
ACHTUNG!<\/b> Alles, was oben beschrieben wurde, ist f\u00fcr 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\u00e4higkeit erforderlich ist oder wenn er aktuelle Probleme l\u00f6st.<\/p>\n
Zus\u00e4tzliche Materialien:<\/h4>\n
<\/p>\n