it-swarm.com.de

Warum verbrauchen meine XFS-Dateisysteme plötzlich mehr Speicherplatz und sind voll mit spärlichen Dateien?

Ich habe XFS-Dateisysteme fast 10 Jahre lang als Daten-/Wachstumspartitionen auf verschiedenen Linux-Servern ausgeführt.

Ich habe ein seltsames Phänomen bei neueren CentOS/RHEL-Servern mit Version 6.2+ festgestellt.

Die stabile Nutzung des Dateisystems wurde nach der Umstellung auf die neuere Betriebssystemversion von EL6.0 und EL6.1 sehr unterschiedlich. Systeme, die ursprünglich mit EL6.2 + installiert wurden, zeigen dasselbe Verhalten. Anzeigen wilder Schwankungen der Festplattenauslastung auf den XFS-Partitionen (siehe die blaue Linie in der folgenden Grafik).

Vorher und nachher. Das Upgrade von 6.1 auf 6.2 erfolgte am Samstag.xfs graph

Das Festplattenauslastungsdiagramm des letzten Quartals desselben Systems, das die Schwankungen der letzten Woche zeigt.enter image description here

Ich fing an, die Dateisysteme auf große Dateien und außer Kontrolle geratene Prozesse zu überprüfen (Protokolldateien vielleicht?). Ich stellte fest, dass meine größten Dateien unterschiedliche Werte von du und ls meldeten. Ausführen von du mit und ohne --apparent-size Schalter zeigt den Unterschied.

# du -skh SOD0005.TXT
29G     SOD0005.TXT

# du -skh --apparent-size SOD0005.TXT
21G     SOD0005.TXT

Eine schnelle Überprüfung mit dem Dienstprogramm Dienstprogramm ncd im gesamten Dateisystem ergab:

Total disk usage: 436.8GiB  Apparent size: 365.2GiB  Items: 863258

Das Dateisystem ist voll von spärlichen Dateien , mit fast 70 GB verlorenem Speicherplatz im Vergleich zur vorherigen Version des Betriebssystems/Kernels!

Ich habe die Red Hat Bugzilla durchgesehen und die Protokolle geändert, um festzustellen, ob Berichte über dasselbe Verhalten oder neue Ankündigungen zu XFS vorliegen.

Nada.

Ich ging von der Kernel-Version 2.6.32-131.17.1.el6 zu 2.6.32-220.23.1. el6 während des Upgrades; Keine Änderung der Nebenversionsnummer.

Ich habe die Dateifragmentierung mit dem Tool filefrag überprüft. Einige der größten Dateien auf der XFS-Partition hatten Tausende von Speicherbereichen. Laufen auf Online-Defragmentierung mit xfs_fsr -v hat während einer langsamen Aktivitätsperiode dazu beigetragen, die Festplattennutzung vorübergehend zu reduzieren (siehe Mittwoch in der ersten Grafik oben). Die Nutzung stieg jedoch sprunghaft an, sobald die schwere Systemaktivität wieder aufgenommen wurde.

Was passiert hier?

64
ewwhite

Ich habe dieses Problem auf eine Diskussion über ein Commit für XFS-Quellbaum vom Dezember 2010 zurückgeführt. Der Patch wurde in Kernel 2.6.38 eingeführt (und später offensichtlich in einige beliebte Linux-Distributionskerne zurückportiert).

Die beobachteten Schwankungen bei der Festplattennutzung sind auf eine neue Funktion zurückzuführen. XFS Dynamic Speculative EOF Preallocation .

Dies ist ein Schritt, um die Dateifragmentierung während Streaming-Schreibvorgängen zu verringern, indem mit zunehmender Dateigröße spekulativ Speicherplatz zugewiesen wird. Der pro Datei vorab zugewiesene Speicherplatz ist dynamisch und hängt in erster Linie vom freien Speicherplatz im Dateisystem ab (um zu verhindern, dass der Speicherplatz vollständig ausgeht).

Es folgt diesem Zeitplan:

freespace       max prealloc size
  >5%             full extent (8GB)
  4-5%             2GB (8GB >> 2)
  3-4%             1GB (8GB >> 3)
  2-3%           512MB (8GB >> 4)
  1-2%           256MB (8GB >> 5)
  <1%            128MB (8GB >> 6)

Dies ist eine interessante Ergänzung des Dateisystems, da es bei einigen der massiv fragmentierten Dateien, mit denen ich mich befasse, hilfreich sein kann.

Der zusätzliche Speicherplatz kann vorübergehend zurückgefordert werden, indem der Seitencache, die Einträge und die Inodes freigegeben werden mit:

sync; echo 3 > /proc/sys/vm/drop_caches

Die Funktion kann vollständig deaktiviert werden, indem während des Dateisystem-Mount ein allocsize -Wert definiert wird. Der Standardwert für XFS ist allocsize=64k.

Die Auswirkungen dieser Änderung werden wahrscheinlich von Überwachungs-/Schwellenwertsystemen (wie ich sie festgestellt habe) zu spüren sein, haben sich aber auch auf Datenbanksysteme ausgewirkt und können zu unvorhersehbaren oder unerwünschten Ergebnissen für Thin-Provisioning Virtual Machines und führen Speicher-Arrays (sie belegen mehr Speicherplatz als erwartet).

Alles in allem hat es mich überrascht, weil es keine klare Ankündigung der Änderung des Dateisystems auf Verteilungsebene oder sogar bei der Überwachung der XFS-Mailingliste gab.


Bearbeiten :
Die Leistung auf XFS-Volumes mit dieser Funktion wird drastisch verbessert. Ich sehe eine konsistente Fragmentierung von <1% auf Volumes, die zuvor eine Fragmentierung von bis zu 50% aufwiesen. Die Schreibleistung ist weltweit hoch!

Statistiken aus demselben Datensatz, die Legacy-XFS mit der Version in EL6.3 vergleichen.

Alt:

# xfs_db -r -c frag /dev/cciss/c0d0p9
actual 1874760, ideal 1256876, fragmentation factor 32.96%

Neu:

# xfs_db -r -c frag /dev/sdb1
actual 1201423, ideal 1190967, fragmentation factor 0.87%
78
ewwhite