{"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":"

Die \u00dcbersetzung des Artikels wurde im Vorfeld des Starts des Kurses vorbereitet \u201eAdministrator Linux. Professionell\u201c<\/a><\/noindex>.<\/i><\/b><\/p>\n

\"Konfiguration<\/p>\n

Es tauchen regelm\u00e4\u00dfig Fragen zu den Empfehlungen von Gluster bez\u00fcglich der Kernelkonfiguration auf und ob diese notwendig sind.<\/p>\n

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\u00f6glichkeit dazu gibt, unter anderem f\u00fcr das Caching als prim\u00e4ren Weg zur Leistungssteigerung.<\/a><\/noindex><\/p>\n

In den meisten F\u00e4llen funktioniert es hervorragend, kann jedoch bei hoher Auslastung zu Problemen f\u00fchren. <\/p>\n

Wir haben viel Erfahrung mit speicherintensiven Systemen wie CAD, EDA und \u00e4hnlichem, 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 \u00dcberlastungen, enormen iowait, Kernel-Fehlern (Kernel Oops), H\u00e4ngern usw. <\/p>\n

Dieser Artikel ist das Ergebnis vieler Experimente zur Anpassung von Parametern, die in verschiedenen Situationen durchgef\u00fchrt wurden. Dank dieser Parameter hat sich nicht nur die Reaktionsf\u00e4higkeit im Allgemeinen verbessert, sondern auch die Stabilit\u00e4t des Clusters erheblich gesteigert.<\/p>\n

Wenn es um die Konfiguration des Speichers geht, sollte man zun\u00e4chst das virtuelle Speichersystem (VM, virtual memory) betrachten, das viele Optionen bietet, die verwirrend sein k\u00f6nnen.<\/p>\n

vm.swappiness<\/h4>\n

\nParameter vm.swappiness<\/code> bestimmt, wie stark der Kernel das Swapping im Vergleich zum Arbeitsspeicher nutzt. Im Quellcode ist er auch als \u201etendency to steal mapped memory\u201c (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\u00f6her der Wert vm.swappiness<\/code>, desto mehr wird das System Swap verwenden.<\/p>\n

Ein hohes Ma\u00df an Swapping ist unerw\u00fcnscht, da gro\u00dfe Datenbl\u00f6cke in den Arbeitsspeicher geladen und ausgelagert werden. Viele behaupten, der Swappiness-Wert sollte hoch sein, aber nach meiner Erfahrung f\u00fchrt die Einstellung auf \u201e0\u201c zu einer Leistungssteigerung.<\/p>\n

Weitere Informationen sind hier zu finden \u2013 lwn.net\/Articles\/100978<\/a><\/noindex> <\/p>\n

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

vm.vfs_cache_pressure<\/h4>\n

\nDieser Parameter steuert den vom Kernel verwendeten Speicher zur Zwischenspeicherung von Verzeichnisobjekten und Indexbeschreibungen (dentry und inode).<\/p>\n

Bei einem Standardwert von 100 versucht der Kernel, den dentry- und inode-Cache \u201efair\u201c im Verh\u00e4ltnis zum pagecache und swapcache freizugeben. Eine Verringerung von vfs_cache_pressure f\u00fchrt dazu, dass der Kernel dentry und inode-Caches beibeh\u00e4lt. Wenn der Wert auf \u201e0\u201c gesetzt ist, wird der Kernel den dentry- und inode-Cache niemals aufgrund von Speichermangel (memory pressure) l\u00f6schen, was leicht zu einem Out-of-Memory-Fehler f\u00fchren kann. Eine Erh\u00f6hung der vfs_cache_pressure \u00fcber 100 f\u00fchrt dazu, dass der Kernel die Auslagerung von dentry und inode priorisiert.<\/p>\n

Bei der Verwendung von GlusterFS k\u00f6nnen viele Benutzer mit gro\u00dfen 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\u00e4chtigen kann, da der Kernel gezwungen ist, Datenstrukturen in einem System mit 40 GB RAM zu verarbeiten. Die Einstellung dieses Wertes \u00fcber 100 hat vielen Benutzern geholfen, eine gerechtere Zwischenspeicherung zu erreichen und die Reaktionsf\u00e4higkeit des Kernels zu verbessern.<\/p>\n

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

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

Der zweite Parameter (vm.dirty_ratio<\/code>) bestimmt den Prozentsatz des Speichers, der von schmutzigen Seiten verwendet werden kann, bevor ein erzwungener R\u00fccklauf (forced flash) beginnt. Wenn dieser Schwellenwert erreicht ist, werden alle Prozesse synchron (blockiert), und sie d\u00fcrfen ihre Arbeit nicht fortsetzen, bis der angeforderte Ein-\/Ausgabevorgang tats\u00e4chlich 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\u00fchren, auf die Ein-\/Ausgabe warten. Dies f\u00fchrt zu vielen h\u00e4ngenden Prozessen, hoher Last, instabiler Systemleistung und schlechten Leistungswerten.<\/p>\n

Eine Verringerung dieser Parameterwerte f\u00fchrt dazu, dass Daten h\u00e4ufiger auf die Festplatte geschrieben werden und nicht im RAM gespeichert bleiben. Dies kann Systemen mit viel Speicher helfen, f\u00fcr die es normal ist, einen Seiten-Cache von 45\u201390 GB auf die Festplatte zu schreiben, was zu enormen Wartezeiten f\u00fcr Frontend-Anwendungen f\u00fchrt und die Gesamterantwortzeit sowie die Interaktivit\u00e4t verringert.<\/p>\n

\u201e1\u201c > \/proc\/sys\/vm\/pagecache<\/h4>\n

\nDer Seiten-Cache ist ein Cache, in dem Daten von Dateien und ausf\u00fchrbaren Programmen gespeichert werden, das hei\u00dft, es handelt sich um 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. Ein Wert von \u201e1\u201c bedeutet, dass 1 % des RAMs f\u00fcr den Cache verwendet werden und es mehr Lesevorg\u00e4nge von der Festplatte als aus dem RAM geben wird. Es ist nicht erforderlich, diesen Parameter zu \u00e4ndern, aber wenn Sie paranoid bez\u00fcglich der Kontrolle \u00fcber den Seiten-Cache sind, k\u00f6nnen Sie ihn anpassen.<\/p>\n

\u201edeadline\u201c > \/sys\/block\/sdc\/queue\/scheduler<\/h4>\n

\nDer I\/O-Scheduler ist ein Kernkomponente von Linux, die Lese- und Schreibwarteschlangen verwaltet. Theoretisch ist es f\u00fcr einen intelligenten RAID-Controller besser, \u201enoop\u201c zu verwenden, da Linux nichts \u00fcber die physische Geometrie der Festplatte wei\u00df. Daher ist es effizienter, dem Controller, der die Geometrie der Festplatte gut kennt, zu erm\u00f6glichen, die Anfrage so schnell wie m\u00f6glich zu bearbeiten. Es scheint jedoch, dass \u201edeadline\u201c die Leistung verbessert. Weitere Details zu den Planern finden Sie in der Dokumentation zum Quellcode des Linux-Kernels: linux\/Documentation\/block\/*osched.txt<\/code>. Au\u00dferdem habe ich einen Anstieg der Leseleistung bei gemischten Operationen (viele Schreibvorg\u00e4nge) beobachtet.<\/p>\n

\u201e256\u201c > \/sys\/block\/sdc\/queue\/nr_requests<\/h4>\n

\nDie Anzahl der Ein- und Ausgabeforderungen 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 I\/O-Schedulers, sodass der I\/O-Scheduler kaum in der Lage ist, die Anfragen richtig 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 Zusammenf\u00fchren und Umordnen von Anfragen hilft dem Scheduler, unter hoher Last reaktionsschneller zu sein.<\/p>\n

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

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

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

\nDie Standardeinstellungen f\u00fcr Blockger\u00e4te vieler RAID-Controller f\u00fchren oft zu einer katastrophalen Leistung. Das Hinzuf\u00fcgen der oben genannten Option konfiguriert das vorzeitige Lesen f\u00fcr 4096 * 512-Byte-Sektoren. Zumindest bei Streaming-Operationen erh\u00f6ht sich die Geschwindigkeit, indem der integrierte Cache der Festplatte durch vorzeitiges Lesen w\u00e4hrend des Zeitraums gef\u00fcllt wird, den der Kernel zur Vorbereitung von I\/O nutzt. Daten, die bei der n\u00e4chsten Leseanfrage angefordert werden, k\u00f6nnen im Cache abgelegt werden. Ein zu gro\u00dfes vorzeitiges Lesen kann den zuf\u00e4lligen I\/O f\u00fcr gro\u00dfe Dateien beeintr\u00e4chtigen, wenn es potenziell n\u00fctzliche Disk-Zeit nutzt oder Daten au\u00dferhalb des Caches l\u00e4dt.<\/p>\n

Hier sind einige weitere Empfehlungen auf Dateisystemebene. 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, dass es sich um ein RAID5-Array mit einer Stripe-Gr\u00f6\u00dfe von 64K aus sechs Festplatten handelt (tats\u00e4chlich aus f\u00fcnf, da eine Festplatte f\u00fcr die Parit\u00e4t verwendet wird). Diese Empfehlungen basieren auf theoretischen Annahmen und stammen aus verschiedenen Blogs\/Artikeln von RAID-Experten.<\/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 kann man in Betracht ziehen, die oben angegebenen Stripe-Gr\u00f6\u00dfen zu erh\u00f6hen.<\/p>\n
ACHTUNG!<\/b> Alles, was oben beschrieben ist, ist f\u00fcr 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\u00e4higkeit zu verbessern oder wenn er aktuelle Probleme l\u00f6st.<\/p>\n
Zus\u00e4tzliche Materialien:<\/h4>\n
<\/p>\n