Optimieren Sie ext4 für immer vollen Betrieb

Unsere Anwendung schreibt Daten als riesigen Ringpuffer (30 bis 150 TB) auf die Festplatte. Schreiben neuer Dateien beim Löschen alter Dateien. Daher ist die Festplatte per Definition immer "nahezu voll".

Der Schriftsteller Prozess verschiedene Dateien zu einer Netto-Eingangsdrehzahl von etwa 100 bis 150 Mbits / s schafft. Datendateien sind eine Mischung aus 1 GB-Datendateien und mehreren kleineren Metadatendateien. (Die Eingabegeschwindigkeit ist konstant. Beachten Sie jedoch, dass neue Dateigruppen nur einmal pro zwei Minuten erstellt werden.)

Es gibt ein separates deleter Verfahren, das die „ältesten“ Dateien alle 30s löscht. Es wird so lange gelöscht, bis dort 15 GB freier Speicherplatz auf der Festplatte erreicht sind.

Im stabilen Betrieb haben alle Datenpartitionen nur 15 GB freien Speicherplatz.

Zu dieser SO-Frage im Zusammenhang mit der Verlangsamung des Dateisystems kommentierte DepressedDaniel :

Das Hängen der Synchronisierung bedeutet nur, dass das Dateisystem hart daran arbeitet, die neuesten Vorgänge konsistent zu speichern. In dieser Zeit wird mit Sicherheit versucht, Daten auf der Festplatte zu mischen. Ich kenne die Details nicht, aber ich bin mir ziemlich sicher, dass ext4 versuchen wird, etwas dagegen zu unternehmen, wenn Ihr Dateisystem stark fragmentiert ist. Und das kann nicht gut sein, wenn das Dateisystem fast 100% voll ist. Die einzig vernünftige Möglichkeit, ein Dateisystem mit nahezu 100% der Kapazität zu verwenden, besteht darin, es statisch mit einigen Dateien zu initialisieren und diese Dateien dann zu überschreiben (um eine Fragmentierung zu vermeiden). Funktioniert wahrscheinlich am besten mit ext2 / 3.

Ist ext4 eine schlechte Wahl für diese Anwendung? Welche Optimierung kann ext4 vorgenommen werden, um Fragmentierung, Verlangsamungen oder andere Leistungseinschränkungen zu vermeiden, da wir live ausgeführt werden? Ein Wechsel von ext4 wäre ziemlich schwierig ...

(und das Umschreiben statisch erstellter Dateien bedeutet das Umschreiben der gesamten Anwendung)

Vielen Dank!

BEARBEITEN I.

An den Server sind 50 bis 100 TB Festplatten angeschlossen (24 Laufwerke). Der Areca RAID-Controller verwaltet die 24 Laufwerke als RAID-6-RAID-Set.

Von dort aus teilen wir uns in mehrere Partitionen / Volumes auf, wobei jedes Volume 5 bis 10 TB beträgt. Die Größe eines Volumes ist also nicht sehr groß.

Der "Writer" -Prozess findet das erste Volume mit "genügend" Speicherplatz und schreibt dort eine Datei. Nachdem die Datei geschrieben wurde, wird der Vorgang wiederholt.

Bei einer brandneuen Maschine werden die Volumina der Reihe nach aufgefüllt. Wenn alle Volumes "voll" sind, beginnt der Prozess "Löschen" mit dem Löschen der ältesten Dateien, bis "genügend" Speicherplatz verfügbar ist.

Aufgrund der Wirkung anderer Prozesse wird die zeitliche Abfolge von Dateien über einen langen Zeitraum zufällig auf alle Volumes verteilt.

EDIT II

Laufen fsckzeigt eine sehr geringe Fragmentierung: 1 - 2%. Doch in der Zwischenzeit hat sich langsam Dateisystemzugriff wurde wie auf verschiedene Systemaufrufe verfolgt fclose(), fwrite(), ftello()usw. eine sehr lange Zeit auszuführen (5 bis 60 Sekunden!).

Bisher keine Lösung für dieses Problem. Weitere Details finden Sie in dieser SO-Frage: Wie debugge ich sehr langsam (200 Sek.) Fwrite () / ftello () / fclose ()?

Ich habe deaktiviert sysstatund um raid-checkzu sehen, ob es Verbesserungen gibt.

Im Prinzip verstehe ich nicht, warum strenge Ringpuffer-Schreibvorgänge eine Herausforderung hinsichtlich der Fragmentierung darstellen würden. Es scheint einfach zu sein. Das Zitat klingt für mich so, als ob es auf Ratschlägen allgemeinerer Schreibarbeitslasten basiert. Aber wenn ich mir die verknüpfte SO-Frage ansehe, sehe ich, dass Sie ein echtes Problem haben ...

Da Sie sich Sorgen über die Fragmentierung machen, sollten Sie überlegen, wie Sie diese messen können! e4defragexistiert. Es gibt nur zwei Möglichkeiten. -cZeigt nur den aktuellen Status an und defragmentiert nicht. -vZeigt Statistiken pro Datei an. Alle Kombinationen von Optionen sind gültig (einschließlich keiner Optionen). Obwohl es keine explizite Methode zur Begrenzung der Auswirkungen auf die Leistung eines laufenden Systems bietet, wird e4defragdie Ausführung einzelner Dateien unterstützt, sodass Sie die Rate selbst einschränken können.

(XFS hat auch ein Defragmentierungswerkzeug, obwohl ich es nicht verwendet habe.)

e2freefragkann Fragmentierung des freien Speicherplatzes zeigen. Wenn Sie den CFQ-E / A-Scheduler verwenden, können Sie ihn mit einer reduzierten E / A-Priorität verwenden ionice.

Das Zitat vermutet falsch, die Antwort von Stephen Kitt ist richtig. ext4 führt keine automatische Defragmentierung durch. Es wird nicht versucht, bereits geschriebene Daten zu "mischen".

Das Verwerfen dieses seltsamen Missverständnisses lässt keinen Grund, "ext2 / ext3" vorzuschlagen. Abgesehen von allem anderen existiert der ext3-Code in aktuellen Kerneln nicht. Der ext4-Code wird zum Mounten von ext3 verwendet. ext3 ist eine Teilmenge von ext4. Insbesondere wenn Sie relativ große Dateien erstellen, erscheint es einfach albern, keine Extents zu verwenden, und diese sind eine ext4-spezifische Funktion.

Ich glaube, "hängen" wird häufiger mit dem Tagebuch in Verbindung gebracht. Siehe z. B. Kommentare von (dem in Bearbeitung befindlichen Dateisystem) bcachefs -

Die Schwanzlatenz ist seit vielen Jahren der Fluch von ext4-Benutzern - Abhängigkeiten im Journalcode und anderswo können zu Latenzen von mehr als 30 Sekunden bei einfachen Vorgängen (z. B. Aufheben der Verknüpfung) bei Multithread-Workloads führen. Niemand scheint zu wissen, wie man sie repariert.

In bcachefs ist der einzige Grund, warum ein Thread E / A blockiert, die explizite Aufforderung (ein nicht zwischengespeicherter Lesevorgang oder eine fsync-Operation) oder die Erschöpfung von Ressourcen - Punkt. Sperren, die Vordergrundoperationen blockieren würden, werden während der E / A nie gehalten. Während bcachefs heute kein Echtzeit-Dateisystem ist (es fehlt beispielsweise die Echtzeitplanung für E / A), könnte es sehr wahrscheinlich eines Tages sein.

Bitten Sie mich nicht zu interpretieren, inwieweit die Verwendung von XFS das oben genannte Problem vermeiden kann. Ich weiß es nicht. Wenn Sie jedoch überlegen, ein alternatives Dateisystem-Setup zu testen, ist XFS das erste, was ich versuchen würde.

Ich habe Probleme, viele Informationen über die Auswirkungen der Deaktivierung von Journalling auf ext4 zu finden. Zumindest scheint dies keine der gängigen Optionen zu sein, die bei der Leistungsoptimierung in Betracht gezogen werden.

Ich bin nicht sicher, warum Sie sys_sync () verwenden. Es wird normalerweise besser vermieden (siehe zB hier ). Ich bin mir nicht sicher, ob das Ihr Problem wirklich erklärt, aber es scheint eine unglückliche Sache zu sein, wenn Sie versuchen, dies einzugrenzen.

Hier ist ein alternativer Ansatz, der jedoch etwas kompliziert ist.

Erstellen Sie viele kleinere Partitionen, sagen wir 10 oder 20 davon. LVM2 kann in diesem Szenario nützlich sein. Verwenden Sie dann die Partitionen wie folgt in einem Ringpuffer:

Eine der Partitionen ist immer die "aktive", in die neue Daten geschrieben werden, bis sie vollständig oder fast vollständig sind. Sie müssen keine Kopffreiheit lassen. Wenn die aktive Partition voll geworden ist oder nicht genügend freien Speicherplatz für den nächsten Datenblock hat, wechseln Sie zur nächsten Partition, die dann zur aktiven Partition wird.

Ihr Löschvorgang stellt immer sicher, dass mindestens eine vollständig leere Partition verfügbar ist. Wenn es keine gibt - und dies ist der entscheidende Teil -, wird einfach die älteste Partition neu formatiert und ein neues Dateisystem erstellt. Diese neue Partition kann später neue Daten mit minimaler bis keiner Fragmentierung empfangen.