Aktuelle Versionen von RHEL / CentOS (EL6) haben einige interessante Änderungen an dem XFS-Dateisystem gebracht, von dem ich seit über einem Jahrzehnt stark abhängig bin . Ich habe einen Teil des letzten Sommers damit verbracht, eine XFS-Sparse- Dateisituation aufzuspüren , die auf einen schlecht dokumentierten Kernel-Backport zurückzuführen ist. Andere hatten unglückliche Leistungsprobleme oder ein inkonsistentes Verhalten, seit sie zu EL6 gewechselt sind.
XFS war mein Standarddateisystem für Daten und Wachstumspartitionen, da es Stabilität, Skalierbarkeit und eine gute Leistungssteigerung gegenüber den Standard-ext3-Dateisystemen bot.
Es gibt ein Problem mit XFS auf EL6-Systemen, das im November 2012 aufgetreten ist. Ich habe festgestellt, dass meine Server selbst im Leerlauf eine ungewöhnlich hohe Systemlast aufwiesen. In einem Fall würde ein unbeladenes System einen konstanten Lastdurchschnitt von 3+ anzeigen. In anderen Fällen gab es einen Anstieg der Ladung um 1+. Die Anzahl der gemounteten XFS-Dateisysteme schien den Schweregrad der Lastzunahme zu beeinflussen.
Das System verfügt über zwei aktive XFS-Dateisysteme. Die Auslastung beträgt nach dem Upgrade auf den betroffenen Kernel +2.
Bei näherer Betrachtung fand ich einige Threads in der XFS-Mailingliste , die auf eine erhöhte Häufigkeit des xfsaildProzesses im Status STAT D hinwiesen . Die entsprechenden Einträge zu CentOS Bug Tracker und Red Hat Bugzilla beschreiben die Besonderheiten des Problems und schließen daraus, dass es sich nicht um ein Leistungsproblem handelt. nur ein Fehler bei der Meldung der Systemlast in Kerneln neuer als 2.6.32-279.14.1.el6 .
WTF?!?
Ich verstehe, dass die Lastberichterstattung in einer einmaligen Situation keine große Sache sein kann. Versuchen Sie, dies mit Ihrem NMS und Hunderten oder Tausenden von Servern zu verwalten! Dies wurde im November 2012 am Kernel 2.6.32-279.14.1.el6 unter EL6.3 identifiziert. Die Kernel 2.6.32-279.19.1.el6 und 2.6.32-279.22.1.el6 wurden in den folgenden Monaten (Dezember 2012 und Februar 2013) ohne Änderung dieses Verhaltens veröffentlicht. Es gibt sogar eine neue kleinere Version des Betriebssystems, seitdem dieses Problem erkannt wurde. EL6.4 wurde veröffentlicht und ist jetzt auf Kernel 2.6.32-358.2.1.el6 , der das gleiche Verhalten aufweist.
Ich hatte eine neue Warteschlange für die Systemerstellung und musste das Problem umgehen, indem ich entweder die Kernelversionen für EL6.3 vor November 2012 sperrte oder einfach XFS nicht verwendete, wobei ich mich für ext4 oder ZFS entschied , was zu erheblichen Leistungseinbußen führte für die spezifische benutzerdefinierte Anwendung, die auf ausgeführt wird. Die betreffende Anwendung stützt sich stark auf einige der XFS-Dateisystemattribute, um Mängel im Anwendungsdesign zu berücksichtigen.
Hinter Red Hats kostenpflichtiger Knowledgebase-Site wird ein Eintrag angezeigt, der Folgendes enthält :
Nach der Installation von Kernel 2.6.32-279.14.1.el6 wird ein Durchschnitt für hohe Auslastung festgestellt. Der Durchschnitt der hohen Auslastung wird dadurch verursacht, dass xfsaild für jedes XFS-formatierte Gerät in den Status D wechselt.
Derzeit gibt es keine Lösung für dieses Problem. Es wird derzeit über Bugzilla # 883905 verfolgt. Umgehung Führen Sie ein Downgrade des installierten Kernelpakets auf eine Version vor 2.6.32-279.14.1 durch.
(mit Ausnahme von Kernel-Downgrades, die unter RHEL 6.4 keine Option sind ...)
Wir sind also schon mehr als 4 Monate in diesem Problem, ohne dass eine echte Korrektur für die EL6.3- oder EL6.4-Betriebssystemversionen geplant ist. Es gibt ein vorgeschlagenes Update für EL6.5 und einen Kernel Source Patch ... Aber meine Frage ist:
Ab wann ist es sinnvoll, von den vom Betriebssystem bereitgestellten Kernels und Paketen abzuweichen, wenn der Upstream-Betreuer eine wichtige Funktion verletzt hat?
Red Hat hat diesen Bug eingeführt. Sie sollten einen Fix in einen Errata-Kernel integrieren. Einer der Vorteile der Verwendung von Unternehmensbetriebssystemen besteht darin, dass sie ein konsistentes und vorhersehbares Plattformziel bieten . Dieser Fehler störte Systeme, die sich bereits während eines Patch-Zyklus in der Produktion befanden, und verringerte das Vertrauen in die Bereitstellung neuer Systeme. Ich könnte zwar einen der vorgeschlagenen Patches auf den Quellcode anwenden , aber wie skalierbar ist das? Es würde einige Wachsamkeit erfordern, um auf dem neuesten Stand zu bleiben, wenn sich das Betriebssystem ändert.
Was ist der richtige Zug hier?
- Wir wissen, dass dies möglicherweise behoben werden könnte, aber nicht wann.
- Das Unterstützen Ihres eigenen Kernels in einem Red Hat-Ökosystem hat seine eigenen Einschränkungen.
- Was ist der Einfluss auf die Förderfähigkeit des Supports?
- Sollte ich nur einen funktionierenden EL6.3-Kernel auf neu erstellte EL6.4-Server legen, um die richtige XFS-Funktionalität zu erhalten?
- Soll ich nur warten, bis dies offiziell behoben ist?
- Was sagt dies über den Mangel an Kontrolle über die Veröffentlichungszyklen von Linux in Unternehmen aus?
- War es ein Planungs- / Entwurfsfehler, sich so lange auf ein XFS-Dateisystem zu verlassen?
Bearbeiten:
Dieser Patch wurde in das neueste CentOSPlus- Kernel-Release ( Kernel-2.6.32-358.2.1.el6.centos.plus ) integriert. Ich teste dies auf meinen CentOS-Systemen, aber das hilft den Red Hat-basierten Servern nicht viel.