Wie kann man rsync / tar von großen Maildir beschleunigen?

Ich habe einen sehr großen Maildir, den ich mit rsync auf einen neuen Computer (über 100BASE-T) kopiere. Der Fortschritt ist langsam. SEHR LANGSAM. Wie 1 MB / s langsam. Ich denke, das liegt daran, dass viele kleine Dateien in einer Reihenfolge gelesen werden, die im Wesentlichen zufällig ist, wo die Blöcke auf der Festplatte gespeichert sind, was zu einem massiven Suchsturm führt. Ich erhalte ähnliche Ergebnisse, wenn ich versuche, das Verzeichnis zu tarieren. Gibt es eine Möglichkeit, rsync / tar dazu zu bringen, in der Reihenfolge der Festplattenblöcke zu lesen, oder dieses Problem auf andere Weise zu überwinden?

Edit: Ich habe tar cf / dev / zero Maildir / ausprobiert und auf dem alten System hat dies 30 Minuten gedauert! Auf dem neuen System dauerte der gleiche Test 18 Minuten, als der Rsync endlich beendet war. Das Speichern des gleichen Verzeichnisses auf dem alten System dauerte 8 Minuten, und auf dem neuen System war das Speichern von -0f / dev / zero -b 1024 / home / psusi / Maildir / in nur 30 Sekunden abgeschlossen.

— psusi
quelle

Antworten:

Am Ende habe ich ein kleines Python-Skript geschrieben, um die Korrelation zwischen Verzeichnisnamen und Inodes, Inodes und Datenblöcken sowie Verzeichnisnamen zu Datenblöcken zu berechnen. Es stellt sich heraus, dass ext4 tendenziell eine eher schlechte Korrelation zwischen der Reihenfolge, in der die Dateinamen im Verzeichnis angezeigt werden, und der Position, in der sie auf der Festplatte gespeichert sind, aufweist. Nach der Diskussion in der ext4-Mailingliste stellt sich heraus, dass dies das Ergebnis der Hash-Verzeichnisindizes ist, mit denen die Suche in großen Verzeichnissen beschleunigt wird. Die Namen werden in Hash-Reihenfolge gespeichert, wodurch ihre Reihenfolge relativ zu allem anderen effektiv verschlüsselt wird.

Es scheint mir und mindestens einem anderen Kommentator, dass dies ein Mangel an fs ist, der behoben werden sollte. Ted Ts'o (der ext-Betreuer) ist der Meinung, dass es zu schwierig wäre, dies in der fs zu tun, und dass gute Tools (wie rsync und tar) die Option haben sollten, das Verzeichnis vor der Inode-Nummer zu sortieren, bevor die Dateien gelesen werden.

Es sieht also so aus, als müssten Anfragen zur Funktionserweiterung für rsync und tar eingereicht werden.

— psusi
quelle

Vielen Dank für Ihre Erkenntnisse. Scheint wie Informationen, die eines Tages nützlich sein könnten.

— Andol

Ich muss Ted Ts'o zustimmen, dass die Leistung für diesen Anwendungsfall auf Anwendungsebene festgelegt werden muss. Es gibt keinen Grund anzunehmen, dass Dateidaten in alphabetischer Reihenfolge auf dem Speichergerät gespeichert werden sollten. Wenn eine andere Anwendung Dateien in der Reihenfolge der letzten Änderungszeit lesen möchte, kann der fs ohnehin nicht beide Vorgänge mit hoher Geschwindigkeit ausführen.

— Mikko Rantalainen

@MikkoRantalainen, hier geht es nicht darum, welche willkürliche Reihenfolge die Anwendung "will", sondern welche beste Reihenfolge davon abhängt, wie das Dateisystem intern funktioniert. Es ist nicht wirklich zu erwarten, dass Anwendungen dies wissen. Daher sollten die fs versuchen, sicherzustellen, dass die Dateien in der besten Reihenfolge zum Lesen aufgelistet werden, was möglicherweise nicht immer in der Reihenfolge der Inode erfolgt.

— Psusi

@psusi, wie soll die fs mit dem Fall umgehen, dass Sie zwei Anwendungen haben, für die Dateien in unterschiedlicher Reihenfolge erforderlich sind? Die fs können die physische Speicherreihenfolge nicht für beide optimieren! Jede an Leistung interessierte Anwendung sollte Dateien in Speicherreihenfolge von der fs anfordern. Wenn POSIX eine solche Reihenfolge nicht zulässt (außer nach Inode-Reihenfolge, die möglicherweise mit der tatsächlichen physischen Speicherreihenfolge übereinstimmt oder nicht), ist dies ein Mangel von POSIX und nicht von fs.

— Mikko Rantalainen

@MikkoRantalainen, die Bestellung ist keine Anforderung der Anwendung, es ist eine Anforderung des Dateisystems, daher sollte das Dateisystem sie bestellen, aber es ist am besten.

— Psusi

Einige Punkte zu beachten:

Über wie viele Dateien sprechen wir? find /path/to/your/maildir/ | wc -lsollte Ihnen einen groben Hinweis geben. Hunderttausende sollten in Ordnung sein. Hunderte von Millionen könnten darauf hindeuten, dass Sie beschneiden, archivieren und allgemein bereinigen müssen.
Ist die Festplatte langsam? Es stehen viele Benchmarks zur Verfügung, darunter ein umfassender bonnie++bis hin zum schnellen und einfachen Disk Utility-Benchmarker. Führen Sie eine aus und sehen Sie, ob Sie leiden.
- Dies kann zu Hardwareproblemen führen - ersetzen Sie diese durch etwas schnelleres
- Probleme mit dem Dateisystem - Verwenden Sie etwas, von dem bekannt ist, dass es bei hohen zufälligen Lese-IOPS sehr langsam ist?

Aber letztlich tarRing und dann die Übertragung sollten Sie den besten auf Kosten der Gesamtdurchsatz geben von Ihnen benötigen es , um die Übertragung aufzubauen , sobald Sie den Teer erzeugt haben.

— Oli
quelle

Vielleicht hunderttausend Dateien, aber nicht Millionen. Die Festplatte des alten Systems erreicht ungefähr 50-60 MBit / s, und das neue System ist ein RAID5, der ungefähr 160 Datenträger ausführt. Beide überschreiten deutlich die 11 MBit / s, die das schnelle Ethernet verarbeiten kann. Das Problem scheint das Direktzugriffsmuster zu sein.

— Psusi

Versuchen Sie, die Deaktivierung der Zeiterfassung zu deaktivieren oder die relative Zeit auf der neuen Festplattenpartition zu verwenden. Dies begrenzt den Overhead. Der Wechsel von einem Nicht-Journaling-Dateisystem wie ext2 zu einem Journaling-Dateisystem wie ext3 oder ext4 führt zu einigen Leistungseinbußen

Als ich Maildirs verlegte, führte ich eine vorbereitende Synchronisierung durch, um alle Verzeichnisse im Voraus einzurichten. Dann gab es nur noch Updates zu tun.

Wenn Sie bereit sind, den eigentlichen Schritt auszuführen, möchten Sie möglicherweise sicherstellen, dass die Verzeichnisse stabil sind.

Versetzen Sie den SMTP-Dämon in den Nur-Warteschlangen-Modus.
Deaktivieren Sie die Warteschlange, die vom SMTP-Dämon ausgeführt wird, und
Deaktivieren Sie den Zugriff durch den Benutzer.

Reaktivieren Sie nach dem Verschieben der Datei.

EDIT: Ich denke, Sie haben das Problem identifiziert. Tar und rsync durchsuchen beide die Verzeichnisse. Aufgrund normaler Dateiänderungen im Maildir werden Dateien für jedes Verzeichnis auf der Festplatte verteilt. Ein Tool wie dump würde die Partition in Blockreihenfolge lesen, das Problem jedoch auf die neue Partition replizieren. Ein zweiter Rsync sollte viel schneller als der zweite ausgeführt werden.

— BillThor
quelle

Tar umgeht atime-Updates, und ich denke, rsync auch. Dies ist mit ext4.

— Psusi

@psusi: Atime-Änderungen sind allgemeine Korrekturen für stark gelesene Partitionen. Beim zweiten Gedanken wird es nicht helfen, Dateien von tar oder rsync zu schreiben. Die Verzeichnisse werden trotzdem geschrieben.

— BillThor

Dump repliziert das Problem nicht auf die neue Partition. Während dump das Raw-Block-Gerät liest, schreibt die Wiederherstellung nicht auf das Raw-Block-Gerät. es geht durch die normale Datei IO. Ich glaube auch, dass Dump in Inode-Reihenfolge liest. Dies ist der Grund, warum es auf der neuen Festplatte so schnell war, da es wahrscheinlich eine sehr starke Korrelation zwischen Inode und Blockreihenfolge gibt, aber auf der alten Festplatte war diese Korrelation nicht so stark, aber besser als die Korrelation zwischen Dateinamen und Blöcken warum es viel besser als Teer tat.

— Psusi

@psusi: Es kann jeden freien Speicherplatz komprimieren, aber die Inodes in einem älteren Maildir-Verzeichnis sind relativ zufällig, ebenso wie der Blockspeicherort der Dateien. Dateien können verschoben werden, aber die Zufälligkeit des Speicherorts bleibt wahrscheinlich bestehen. Es mag etwas besser sein, könnte aber schlechter sein. rsync und tar sollten die Inodes und die Speicherplatzzuweisung relativ sequentiell machen, insbesondere auf einer neuen Partition. Der zweite von mir vorgeschlagene Rsync startet den Randomisierungsprozess.

— BillThor

@ BillThor ja, ob sie über rsync, tar oder dump zur neuen Partition gelangen, sie beginnen im Allgemeinen in ziemlich guter Reihenfolge. Die Frage ist, wie man den alten Maildir repariert, damit das Lesen mit tar oder rsync nicht so langsam ist. Oder korrigieren Sie tar und rsync, damit sie in einer optimaleren Reihenfolge lesen.

— Psusi