Von Zeit zu Zeit stellen sich hier und da Fragen zu Glusters Empfehlungen zur Kernel-Optimierung und ob dies erforderlich ist.
Ein solches Bedürfnis ist selten. Der Kernel funktioniert bei den meisten Workloads sehr gut. Obwohl es einen Nachteil gibt. In der Vergangenheit verbraucht der Linux-Kernel bei Gelegenheit leicht viel Speicher, auch für das Caching als Hauptmethode zur Verbesserung der Leistung.
Meistens funktioniert dies einwandfrei, aber unter starker Last kann es zu Problemen kommen.
Wir haben viel Erfahrung mit Systemen, die viel Speicher verbrauchen, wie CAD, EDA und dergleichen, die unter hoher Last langsamer wurden. Und manchmal hatten wir Probleme mit Gluster. Nachdem wir den verwendeten Speicher und die Latenz der Festplatten einige Tage lang sorgfältig beobachtet hatten, stellten wir fest, dass sie überlastet waren, riesige iowait, Kernel-Oops, Einfrierungen usw.
Dieser Artikel ist das Ergebnis vieler Tuning-Experimente, die in verschiedenen Situationen durchgeführt wurden. Diese Parameter verbesserten nicht nur die allgemeine Reaktionsfähigkeit, sondern stabilisierten auch die Clusterleistung erheblich.
Wenn es um die Speicheroptimierung geht, sollten Sie sich zunächst das Subsystem für den virtuellen Speicher (VM) ansehen, das über eine Vielzahl von Optionen verfügt, die Sie verwirren können.
vm.swappiness
Dieser Parameter
vm.swappinessbestimmt, wie oft der Kernel Swap (Swap) im Vergleich zum RAM verwendet. Im Quellcode wird es auch definiert als "Tendenz, zugeordneten Speicher zu stehlen" (Tendenz, zugeordneten Speicher zu stehlen). Ein hoher Swappiness-Wert bedeutet, dass der Kernel anfälliger für das Entladen gerenderter Seiten ist. Ein niedriger Swappiness-Wert bedeutet das Gegenteil: Der Kernel tauscht weniger Seiten aus dem Speicher aus. Mit anderen Worten, je höher der Wert vm.swappiness, desto mehr wird das System tauschen.
Eine starke Verwendung des Austauschs ist unerwünscht, da große Datenblöcke in den RAM geladen und entladen werden. Viele Leute argumentieren, dass der Swapiness-Wert hoch sein sollte, aber meiner Erfahrung nach erhöht das Setzen auf "0" die Leistung.
Weitere Details finden Sie hier -lwn.net/Articles/100978
Aber auch diese Einstellungen sollten mit Vorsicht und erst nach dem Testen einer bestimmten Anwendung angewendet werden. Bei hoch geladenen Streaming-Anwendungen sollte dieser Parameter auf "0" gesetzt werden. Das Ändern auf "0" verbessert die Reaktionsfähigkeit des Systems.
vm.vfs_cache_pressure
Dieser Parameter steuert den Speicher, den der Kernel zum Zwischenspeichern von Verzeichnisobjekten und Inodes (Dentry und Inode) benötigt.
Mit der Standardeinstellung von 100 versucht der Kernel, die Dentry- und Inode-Caches freizugeben, um den Seitencache und den Swapcache zu gewährleisten. Durch Verringern von vfs_cache_pressure behält der Kernel die Dentry- und Inode-Caches bei. Wenn der Wert 0 ist, löscht der Kernel aufgrund des unzureichenden Speicherdrucks niemals die Dentry- und Inode-Caches. Dies kann leicht zu einem Speichermangel führen. Wenn Sie vfs_cache_pressure auf über 100 erhöhen, priorisiert der Kernel das Entladen von Dentry und Inode.
Mit GlusterFS können viele Benutzer mit großen Datenmengen und vielen kleinen Dateien aufgrund von Inode / Dentry-Caching problemlos eine erhebliche Menge an RAM auf dem Server verwenden. Dies kann zu Leistungseinbußen führen, da der Kernel Datenstrukturen auf einem System mit 40 GB Speicher verarbeiten muss ... Das Festlegen dieses Parameters über 100 hat vielen Benutzern geholfen, ein faireres Caching und eine verbesserte Kernel-Reaktionsfähigkeit zu erreichen.
vm.dirty_background_ratio und vm.dirty_ratio
Der erste Parameter (
vm.dirty_background_ratio) definiert den Prozentsatz des Speichers mit fehlerhaften Seiten. Danach muss ein Hintergrund-Flush von fehlerhaften Seiten auf die Festplatte gestartet werden. Bis dieser Prozentsatz erreicht ist, werden keine Seiten auf die Festplatte geleert. Und wenn der Reset startet, läuft er im Hintergrund, ohne die laufenden Prozesse zu unterbrechen.
Der zweite Parameter (
vm.dirty_ratio) definiert den Prozentsatz des Speichers, der von schmutzigen Seiten belegt werden kann, bevor der erzwungene Flash beginnt. Wenn dieser Schwellenwert erreicht ist, werden alle Prozesse synchron (blockiert) und dürfen erst weiter ausgeführt werden, wenn der angeforderte E / A-Vorgang tatsächlich abgeschlossen ist und sich die Daten auf der Festplatte befinden. Bei hoher E / A-Last verursacht dies ein Problem, da kein Daten-Caching stattfindet und alle Prozesse, die E / A ausführen, blockiert sind und auf E / A warten. Dies führt zu einer großen Anzahl eingefrorener Prozesse, hoher Last, instabilem Systembetrieb und schlechter Leistung.
Das Verringern der Werte dieser Parameter führt dazu, dass Daten häufiger auf die Festplatte geschrieben und nicht im RAM gespeichert werden. Dies kann Systemen mit viel Arbeitsspeicher helfen, für die es in Ordnung ist, den 45-90-GB-Seitencache zu leeren, 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, in dem Daten für Dateien und ausführbare Programme gespeichert werden. Dies sind Seiten mit dem tatsächlichen Inhalt von Dateien oder Blockgeräten. Dieser Cache wird verwendet, um die Anzahl der Festplattenlesevorgänge zu verringern. Der Wert "1" bedeutet, dass der Cache 1% des Arbeitsspeichers belegt und mehr Lesevorgänge von der Festplatte als vom Arbeitsspeicher ausgeführt werden. Es ist nicht erforderlich, diesen Parameter zu ändern. Wenn Sie jedoch die Kontrolle über den Seitencache paranoid haben, können Sie ihn verwenden.
Frist> / sys / block / sdc / queue / scheduler
Der E / A-Scheduler ist die Linux-Kernelkomponente, die Lese- und Schreibwarteschlangen verarbeitet. 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, einen Controller mit guten Kenntnissen der Festplattengeometrie die Anforderung so schnell wie möglich verarbeiten zu lassen. Aber die Frist scheint die Leistung zu verbessern. Weitere Informationen zu Schedulern finden Sie in der Dokumentation zum Quellcode des Linux-Kernels :
linux/Documentation/block/*osched.txt. Und ich sah auch einen Anstieg des Lesedurchsatzes bei gemischten Operationen (viele Schreibvorgänge).
"256"> / sys / block / sdc / queue / nr_requests
Die Anzahl der E / A-Anforderungen im Puffer, bevor sie an den Scheduler gesendet werden. Einige Controller haben eine interne Warteschlangengröße (queue_depth), die größer ist als die nr_requests des E / A-Schedulers, sodass der E / A-Scheduler nur geringe Chancen hat, Anforderungen ordnungsgemäß 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 Kombinieren und Neuanordnen von Abfragen kann der Planer unter hoher Last 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 wird der Wert entsprechend der 64-KB-Stripe-Größe des RAID auf "16" gesetzt. Bei swappiness = 0 ist dies nicht sinnvoll. Wenn Sie jedoch 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 / <devname >(-sdb, hdc oder dev_mapper)
Die Standardeinstellungen für Blockgeräte für viele RAID-Controller führen häufig zu einer schrecklichen Leistung. Durch Hinzufügen der obigen Option wird das Vorauslesen für 4096 * 512-Byte-Sektoren konfiguriert. Zumindest für Streaming-Vorgänge wird die Geschwindigkeit erhöht, indem der integrierte Festplatten-Cache während des Zeitraums, den der Kernel für die Vorbereitung der E / A benötigt, mit Vorauslesen gefüllt wird. Der Cache kann Daten enthalten, die beim nächsten Lesen angefordert werden. Zu viel Vorauslesen kann zufällige E / A für große Dateien beenden, wenn möglicherweise nützliche Festplattenzeit verwendet oder Daten außerhalb des Caches geladen werden.
Im Folgenden finden Sie einige weitere Richtlinien auf Dateisystemebene. Sie wurden jedoch noch nicht getestet. Stellen Sie sicher, dass Ihr Dateisystem die Stripe-Größe und die Anzahl der Festplatten im Array kennt. Beispielsweise handelt es sich um ein raid5-Array mit einer 64-KB-Streifengröße von sechs Festplatten (tatsächlich fünf, da eine Festplatte für die Parität verwendet wird). Diese Empfehlungen basieren auf theoretischen Annahmen und wurden von RAID-Experten aus verschiedenen Blogs / Artikeln 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 genannten Streifengrößen zu erhöhen.
BEACHTUNG! Alles, was oben beschrieben wurde, ist für einige Arten von Anwendungen äußerst subjektiv. Dieser Artikel garantiert keine Verbesserung ohne vorherige Benutzertests der jeweiligen Anwendungen. Es sollte nur verwendet werden, wenn die allgemeine Reaktionsfähigkeit des Systems verbessert werden muss oder wenn aktuelle Probleme gelöst werden.
Zusätzliche Materialien:
- dom.as/2008/02/05/linux-io-schedulers
- www.nextre.it/oracledocs/oraclemyths.html
- lkml.org/lkml/2006/11/15/40
- misterd77.blogspot.com/2007/11/3ware-hardware-raid-vs-linux-software.html
Weiterlesen