Optionen für Leistungsverbesserungen bei sehr großen Dateisystemen und hohem IOWAIT

10

Ich habe einen Ubuntu 16.04 Backup Server mit 8x10 TB Festplatte über eine SATA 3.0 Backplane. Die 8 Festplatten sind zu einem RAID6 zusammengebaut, ein EXT4-Dateisystem wird verwendet. Dieses Dateisystem speichert eine große Menge kleiner Dateien mit sehr vielen SEEK-Vorgängen, aber geringem E / A-Durchsatz. Tatsächlich gibt es viele kleine Dateien von verschiedenen Servern, die jeden Tag über rsnapshot aufgenommen werden (mehrere INODES direkt auf dieselben Dateien. Ich habe eine sehr schlechte Leistung, da das Dateisystem (60 TB netto) die Auslastung von 50% überschritten hat Nutzung liegt bei 75% und a

du -sch /backup-root/

dauert mehrere Tage (!). Die Maschine verfügt über 8 Kerne und 16 GB RAM. Der RAM wird vollständig vom OS-Dateisystem-Cache genutzt, 7 von 8 Kernen sind aufgrund von IOWAIT immer inaktiv.

Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          5af205b0-d622-41dd-990e-b4d660c12bd9
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              912203776
Block count:              14595257856
Reserved block count:     0
Free blocks:              4916228709
Free inodes:              793935052
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         2048
Inode blocks per group:   128
RAID stride:              128
RAID stripe width:        768
Flex block group size:    16
Filesystem created:       Wed May 31 21:47:22 2017
Last mount time:          Sat Apr 14 18:48:25 2018
Last write time:          Sat Apr 14 18:48:18 2018
Mount count:              9
Maximum mount count:      -1
Last checked:             Wed May 31 21:47:22 2017
Check interval:           0 (<none>)
Lifetime writes:          152 TB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
First orphan inode:       513933330
Default directory hash:   half_md4
Directory Hash Seed:      5e822939-cb86-40b2-85bf-bf5844f82922
Journal backup:           inode blocks
Journal features:         journal_incompat_revoke journal_64bit
Journal size:             128M
Journal length:           32768
Journal sequence:         0x00c0b9d5
Journal start:            30179

Mir fehlt die Erfahrung mit dieser Art der Dateisystemnutzung. Welche Optionen muss ich einstellen? Welches Dateisystem würde mit diesem Szenario besser abschneiden? Gibt es Optionen, um RAM für andere Caching-Optionen als die im Betriebssystem integrierte einzubeziehen?

Wie gehen Sie mit sehr großen Mengen kleiner Dateien auf großen RAID-Assemblys um?

Danke, Sebastian

t2m
quelle
2
Schnellere Festplatten, vorzugsweise SSD. So viel RAM wie möglich für das Lese-Caching. 16 GB sind nicht einmal auf dem gleichen Planeten wie genügend RAM. Holen Sie sich viel davon, sogar 512 GB oder mehr. Und natürlich nicht RAID 6.
Michael Hampton
Danke für deine Antwort. Mir ist die SSD-Option bekannt, aber dies macht den Unterschied zwischen einem 7000 $ -Server oder einem 70000 $ -Server zum Sichern von Daten. Der RAM-Hinweis ist gut, aber ich befürchte, dass ich nur dann eine jungfräuliche Dateisystemleistung erhalte, wenn ich DISK IO für SEEK-Vorgänge, dh 60 TB netto, vollständig vermeide. Kapazität eines 60 TB RAM Cache, nicht wahr? Ich habe in der Vergangenheit andere Dateisysteme als EXT2 / 3/4 vermieden, aber jetzt bin ich völlig offen für Optionen in diese Richtung, wenn sie helfen. :)
t2m
Was empfehlen Sie für einen RAID6-Ersatz bei dieser Festplattenkonfiguration?
t2m
1
"Tatsächlich gibt es viele kleine Dateien von verschiedenen Servern, die jeden Tag über rsnapshot aufgenommen werden (mehrere INODES direkt zu denselben Dateien." - Ich denke, Sie meinen mehrere Links / Namen zu denselben Inodes. Wenn Sie eine Datei fest verknüpfen, gibt es diese nur ein Inode, aber zwei (oder mehr) Links / Namen.
marcelm
1
Alter, wenn das ein 7000 USD Server ist, dann hör auf, abgezockt zu werden. Wenn Sie dem Server 1000 USD PCIe-SSD hinzufügen, wird er nicht auf magische Weise zu einem 70.000-SSD-Server.
TomTom

Antworten:

11

Ich habe ein ähnliches (wenn auch kleineres) Setup mit 12 x 2 TB Festplatten in einem RAID6-Array, das für denselben Zweck verwendet wird ( rsnapshotSicherungsserver).

Erstens ist es völlig normal du -hs, dass ein so großes und verwendetes Dateisystem so viel Zeit in Anspruch nimmt. Darüber hinaus werden duHardlinks berücksichtigt, die zusätzlich zur offensichtlichen E / A-Last eine erhebliche und hohe CPU-Auslastung verursachen.

Ihre Langsamkeit ist darauf zurückzuführen, dass sich die Metadaten des Dateisystems in sehr weit entfernten (in LBA-Begriffen) Blöcken befinden und viele Suchanfragen verursachen. Da eine normale Festplatte mit 7,2 KB / min ungefähr 100 IOPS bietet, können Sie sehen, wie Stunden, wenn nicht Tage, zum Laden aller Metadaten erforderlich sind.

Etwas, das Sie versuchen können, um die Situation (zerstörungsfrei) zu verbessern:

  • Stellen Sie sicher, dass Sie keinemlocate/slocate Indizierung haben /backup-root/(Sie können die Prunefs-Funktion verwenden , um dies zu vermeiden), da sonst das Sichern des Metadaten-Cache Ihre Sicherungszeit erheblich beeinträchtigt.
  • Aus dem gleichen Grunde laufen, avoid duauf /backup-root/. Führen Sie bei Bedarf dunur den gewünschten Unterordner aus.
  • niedriger vfs_cache_pressurevom Standardwert (100) auf einen konservativeren Wert (10 oder 20). Dadurch wird der Kernel angewiesen, das Zwischenspeichern von Metadaten dem Zwischenspeichern von Daten vorzuziehen. Dies sollte wiederum die rsnapshot/rsyncEntdeckungsphase beschleunigen .
  • Sie können versuchen, ein Gerät zum Durchschreiben von Metadaten hinzuzufügen, z. B. über lvmcache oder bcache . Dieses Metadatengerät sollte offensichtlich eine SSD sein.
  • Erhöhen Sie Ihren verfügbaren RAM.
  • Beachten Sie bei der Verwendung von ext4 die Probleme mit der Inode-Zuweisung (lesen Sie hier ein Beispiel). Dies hängt nicht direkt mit der Leistung zusammen, ist jedoch ein wichtiger Faktor, wenn sich so viele Dateien in einem ext-basierten Dateisystem befinden.

Andere Dinge, die Sie ausprobieren können - aber dies sind destruktive Operationen:

  • Verwenden Sie XFS mit beiden -ftypeund dem -finobtOptionssatz.
  • Verwenden Sie ZFS unter Linux (ZoL) mit komprimiertem ARC und primarycache=metadataEinstellungen (und möglicherweise einem L2ARC für den schreibgeschützten Cache).
Shodanshok
quelle
Vielen Dank für diese Antwort. Wie Sie vielleicht erwartet haben, habe ich jetzt etwas zu lesen. Die Option vfs_cache_pressure ist sehr interessant. Ich habe jetzt einige Minuten mit den Caches herumgespielt und ich denke, das System reagiert etwas schneller (Verzeichnislisten, automatische Vervollständigung usw.). Ich werde auch die anderen Punkte überprüfen und ein Feedback geben. Danke noch einmal.
t2m
"Primärcache = Metadateneinstellung (und möglicherweise ein L2ARC für schreibgeschützten Cache)." ZFS kann nicht beides, ich hatte einen Bericht
poige
@poige Aufgrund der geringen RAM-Menge sprach ich über das Zwischenspeichern von Metadaten in L2ARC (zusätzlich zu dem, was bereits in ARC zwischengespeichert wurde). Schließlich sollte das Zwischenspeichern von Daten für einen rsnapshotSicherungsserver keinen großen Unterschied machen .
Shodanshok
1
Ich stellte klar, dass das einzige, was in L2ARC zu finden ist, Metadaten sind, egal was dann passiert. :) In Bezug auf die RAM-Größe sind 16 GB überhaupt kein RAM für das Gesamtvolumen der Festplatte. Ein angemessenes Minimum wäre etwa 128 GB. Wenn es also trotzdem aktualisiert wird, sind Sie nicht mehr auf 16 GB beschränkt
poige
@marcelm du hast recht: ich habe mich -hfür ganz andere dinge verwirrt ( -Hfür rsync...). Ich habe meine Antwort aktualisiert.
Shodanshok
6

Dieses Dateisystem speichert eine große Menge kleiner Dateien mit sehr vielen SEEK-Vorgängen, aber geringem E / A-Durchsatz.

🎉

Dies ist eine Sache, die heutzutage viele Menschen fängt. Leider skalieren konventionelle FSes hier nicht gut. Ich kann Ihnen wahrscheinlich nur ein paar Ratschläge geben, wenn es um das Setup geht, das Sie bereits haben: EXT4 über RAID-6 auf Festplatten :

  1. Senken Sie vm.vfs_cache_pressurenach unten, sagen zu 1. Es wäre ändern Bias Cachen zu mehr Metadaten zu bewahren (inode, dentry) anstelle von Daten selbst und es soll bei der Verringerung der Zahl positiven Effekt von sucht
  2. Fügen Sie mehr RAM hinzu . Obwohl es für einen Server, auf dem keine Piggy-Apps ausgeführt werden, seltsam aussehen mag, denken Sie daran: Die einzige Möglichkeit, Suchanfragen zu reduzieren, besteht darin, mehr Metadaten in einem schnelleren Speicher zu speichern, da Sie nur über 16 GB verfügen. Dies scheint relativ einfach zu sein Erhöhen Sie die RAM-Größe
  3. Wie ich bereits sagte, ist EXT4 keine gute Wahl für den Anwendungsfall, den Sie haben, aber dennoch können Sie einige der Funktionen nutzen, die es zur Schmerzlinderung bietet:
    • Das externe Journal wird unterstützt, sodass Sie versuchen können, eine SSD (besser gespiegelt) hinzuzufügen und das Journal dort abzulegen. Schauen Sie sich " ext4: Vorbehalte gegen externe Journale " an
    • Versuchen Schaltjournalmodus auf „alle Wesen der Daten selbst im Journal“ Montage mitdata=journal
  4. Versuchen Sie , Dateien außerhalb eines einzelnen FS-Bereichs zu verschieben . Wenn Sie beispielsweise LVM-2 hier haben, können Sie Volumes mit einer geringeren Größe erstellen und diese vorerst verwenden. Wenn es voll ist, erstellen Sie ein weiteres und so weiter.
    • Wenn Sie kein LVM-2 haben, können Sie dies mit / dev / loop versuchen, aber es ist nicht so praktisch und wahrscheinlich weniger performant

UPD. : Da es sich als Linux Software RAID (LSR) RAID-6 herausgestellt hat, folgt hier ein zusätzlicher Punkt:

  1. LSR hat eigene Tuning-Optionen, die viele Leute zu übersehen scheinen
    • Stripe-Cache , der auf diese Weise auf Maximum eingestellt werden kann: echo 32768 | sudo tee /sys/devices/virtual/block/md*/md/stripe_cache_size- Gehen Sie jedoch vorsichtig vor (verwenden Sie bei Bedarf einen geringeren Wert), da die Größe mehrere Blöcke beträgt und je nach gewählter Blockgröße unterschiedlich viel RAM benötigt wird
    • Externes Journal, das sich auch auf diesen gespiegelten SSDs befinden kann ( aber derzeit ohne MD erstelltes MD-Gerät kann nicht in eines konvertiert werden ).

- Das ist wahrscheinlich das meiste, was ohne Neugestaltung verbessert werden kann.

Ich habe eine sehr schlechte Leistung, da das Dateisystem (60 TB netto) 50% der Nutzung überschritten hat. Im Moment liegt die Auslastung bei 75%

Dies ist ein sehr ernstes Problem, da diese hohe Speicherplatzbelegung die Fragmentierung nur verschlimmert. Und mehr Fragmentierung bedeutet mehr Suchen. Ich frage mich nicht mehr, warum es mehr oder weniger akzeptable Leistung erbrachte, bevor es 50% erreichte. Viele Handbücher enthalten klare Empfehlungen, damit FSes nicht hinter 75—80% heranwachsen können.

poige
quelle
Sie deuten eindeutig an, dass ext4 auf Raid-6 nicht der richtige Weg ist. Würde es Ihnen etwas ausmachen, das von Ihnen empfohlene Setup zu skizzieren?
Marcelm
2
Das ist eine zu komplexe Aufgabe, um sie überhaupt zu skizzieren. In einigen Fällen wäre es in Ordnung, konventionelles FS zu wählen, selbst wenn man viele Dateien hat, in anderen (Fällen) ist dies am Anfang nicht möglich. Sie können sich ein gutes Intro ansehen, warum CEPH POSIX FS überhaupt aufgegeben und auf DB umgestellt hat. Übrigens, wenn sie FS verwendeten, bevorzugten sie XFS. Ich würde wahrscheinlich das Gleiche tun. RAID-6 ist der wichtigste IOPS-Multiplikator. Bei jedem Schreibvorgang muss die Parität auf zwei anderen Geräten aktualisiert werden. Also wahrscheinlich eine Art RAID-x0-Ansatz. Mit On-Fly-Komprimierungsunterstützung kann es sinnvoll sein, sogar RAID-10 zu verwenden. Natürlich gibt es Möglichkeiten ...
Poige
1
… Um es durch SSD-Cache (bcache, dm-cache, ZFSs internes ZIL + L2ARC) weiter zu beschleunigen, kann die Praxis jedoch einige ihrer eigenen Einschränkungen haben, die das Umgehen effektiv deaktivieren. Deshalb habe ich "zu komplex" gesagt. Man muss die Anforderungen und Ressourcen kennen, die verfügbar sind, um das Ziel zu erreichen.
Poige
1
Ich verstehe, dass es zu viel verlangt, eine vollständige Lösung zu finden, aber selbst der Braindump, den Sie in den obigen Kommentaren angegeben haben, kann ein guter Ausgangspunkt für weitere Forschungen für alle sein, die mit ähnlichen Problemen konfrontiert sind. danke :)
marcelm
0

RAID6 hilft Ihnen in diesem Fall nicht viel. So etwas wie ZFS ermöglicht möglicherweise einen viel schnelleren Metadaten- und Verzeichniszugriff bei gleichbleibender Geschwindigkeit.

John Keates
quelle
0

RAID-6-Stripes-Laufwerke, daher werden alle E / A-Vorgänge an alle Laufwerke gesendet. Das ist bei vielen kleinen Dateien ziemlich ineffizient. Dies ist jedoch wahrscheinlich nicht Ihr Hauptproblem, das ...

Ext4 ist nicht gut für große Dateisysteme mit Millionen von Dateien geeignet. Verwenden Sie XFS . Ich habe XFS-Dateisysteme mit einer Größe von 1,2 PB und mit bis zu 1 Milliarde Dateien kein Problem. Verwenden Sie einfach XFS .

Wazoox
quelle
0

Vielen Dank an alle, die meine Frage beantwortet haben.

So habe ich es gelöst:

Zunächst habe ich der Karte die maximale RAM-Größe hinzugefügt. Leider unterstützt das Board nur bis zu 64 GB RAM. Ich habe das Verhalten nach der Erweiterung beobachtet und es war enttäuschend. Obwohl der gesamte verfügbare RAM für den E / A-Cache verwendet wurde, verbesserte sich die Leistung des RSNAPSHOT-Backups nicht messbar.

Also musste ich den großen Streitkolben ziehen. Ich habe zwei 1-TB-NVME-Festplatten hinzugefügt und sie zu einem RAID 1 zusammengesetzt. Das RAID 6, bestehend aus 8 x 10 TB-Festplatten, wurde in ein RAID 1 (bestehend aus 2 x 10 TB-Festplatte, ext4) und ein RAID 5 (bestehend aus 6 x 10 TB-Festplatte) zerlegt. Das RAID 1 enthält jetzt das Betriebssystem und die Arbeitskopie der Server (die viermal täglich mit diesem Laufwerk synchronisiert werden).

Das RAID5 ist jetzt ein von BCACHE unterstütztes Gerät, das vom NVME-RAID 1 unterstützt und mit ext4 formatiert wird. Dieses Laufwerk enthält die RSNAPSHOT-Kopien. Jede Nacht werden die Dateien vom RAID1 zum RAID5 synchronisiert, wodurch sich der E / A-Durchsatz des RAID5 im Vergleich zum früheren RAID6, das die Arbeitskopien UND die Backup-Snapshots enthielt, halbiert. Dank des BCache wird nicht buchstäblich jede einzelne Datei auf die Festplatten geschrieben, sondern alle Änderungen in einem Block werden einmal geschrieben, selbst wenn sie mehrere Hundertstel einzelne Dateiänderungen enthalten. Dies verringerte die IOps auf den Festplatten weiter.

Schließlich habe ich meine RSnapshot-Konfiguration geändert. Früher gab es 31 tägliche Snapshots und 18 monatliche Snapshots, was zu 49 Backup-Generationen führte. Jetzt habe ich das klassische 7d / 4w / 12m / 1y-Design, das die Anzahl der Backup-Generationen auf 24 reduziert.

Nach diesen Änderungen (und mit dem oben erwähnten 64 GB RAM) verringerte sich die Dauer für einen Schnappschuss von ~ 20 Stunden auf 1,5 Stunden. Die BCache-Geräte haben eine Cache-Trefferquote von 82% (nach 6 Wochen regulärem Betrieb).

Mission erfüllt. Vielen Dank an euch alle für eure Gedanken und Beiträge.

t2m
quelle