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

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).

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:

5. 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.

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.

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 .

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.