Optimieren des Verhaltens des Linux-Festplatten-Caches für maximalen Durchsatz

Ich habe hier ein Problem mit dem maximalen Durchsatz und brauche Ratschläge, wie ich meine Regler einstellen kann. Wir betreiben einen 10Gbit Fileserver für die Backup Distribution. Es ist ein S-ATA2-Setup mit zwei Festplatten auf einem LSI MegaRAID-Controller. Der Server hat auch 24 GB Speicher.

Wir müssen unser zuletzt hochgeladenes Backup mit maximalem Durchsatz spiegeln.

Das RAID0 für unsere "heißen" Backups gibt uns rund 260 MB / s Schreib- und 275 MB / s Lesegeschwindigkeit. Ein getesteter tmpfs mit einer Größe von 20 GB ergibt ungefähr 1 GB / s. Diese Art von Durchsatz ist das, was wir brauchen.

Wie kann ich nun das virtuelle Speichersubsystem von Linux so einstellen, dass die zuletzt hochgeladenen Dateien so lange wie möglich im Speicher zwischengespeichert werden, ohne dass sie auf die Festplatte geschrieben werden (oder noch besser: auf die Festplatte schreiben UND sie im Speicher behalten)?

Ich habe die folgenden Sysctls eingerichtet, aber sie geben uns nicht den erwarteten Durchsatz:

# VM pressure fixes
vm.swappiness = 20
vm.dirty_ratio = 70
vm.dirty_background_ratio = 30
vm.dirty_writeback_centisecs = 60000

Dies sollte uns theoretisch 16 GB für das Zwischenspeichern von E / A geben und einige Minuten warten, bis es auf die Festplatte geschrieben wird. Wenn ich jedoch den Server einem Benchmarking unterziehe, sehe ich keine Auswirkungen auf das Schreiben, der Durchsatz steigt nicht an.

Hilfe oder Rat benötigt.

— Peter Meyer
quelle

Wäre es nicht sinnvoller, so bald wie möglich mit dem Schreiben zu beginnen? Ansonsten erreicht es die maximale Puffergröße und kommt plötzlich zum Stillstand. Wenn es die ganze Zeit geschrieben hat, bleibt Ihnen mehr Zeit.

— Zan Lynx

Ich habe 20 GB Speicher nur für Puffer, da meine Anwendungen (Basis-Linux + vsftpd) weniger als 4 GB (insgesamt 24 GB) verwenden. Meine Backups sind unter 20GB. Wenn ich sie nach dem Sicherungslauf nacheinander in den Puffer und dann auf die Festplatte schreiben kann, würde dies die Ausfallzeit meiner Sicherungsquelle (virtuelle Server) erheblich reduzieren. PS: Der Server kann danach problemlos zum Stillstand kommen. Es hat 30 Minuten Zeit, sich zu erholen :)

— Peter Meyer

Es hört sich so an, als würde eine beliebige Anwendung, die Sie zum Übertragen der Daten über das Netzwerk verwenden, sie auf die Festplatte synchronisieren. Sie werden es nicht tun wollen, damit die Daten einfach im Cache bleiben, obwohl ich mich frage, warum Sie in der Lage sein wollen, so viele Daten schneller einzusammeln, als die Festplatten mithalten können. Das deutet auf einen Konstruktionsfehler hin.

— Psusi

Das klingt nach dem Manko: Ihre Backup-Lösung sollte nicht erfordern, dass der Server die ganze Zeit heruntergefahren wird.

— Psusi

@PeterMeyer: Auch wenn Sie viel RAM haben, ist es immer noch ein Fehler, auf den Start der Schreibvorgänge zu warten. Die einzige Zeit, die überhaupt Sinn macht, ist, wenn Sie Dateien (wie eine temporäre Datei) bearbeiten oder löschen, bevor sie auf die Festplatte gelangen. Ein Backup macht das nicht. Sie möchten so schnell wie möglich mit dem Schreiben im Hintergrund beginnen. Stellen Sie Ihr background_ratio auf 1 oder 2 ein.

— Zan Lynx

Antworten:

Wenn Sie sich die Variablen ansehen, die Sie festgelegt haben, scheinen Sie hauptsächlich mit der Schreibleistung befasst zu sein und kümmern sich nicht um mögliche Datenverluste aufgrund von Stromausfällen.

Sie erhalten immer nur die Option für verzögertes Schreiben und die Verwendung eines Rückschreibcaches mit asynchronen Schreibvorgängen. Für synchrone Schreibvorgänge muss ein Commit auf die Festplatte ausgeführt werden, und es wird niemals verzögert geschrieben. Ihr Dateisystem verursacht möglicherweise häufige Seitenlöschvorgänge und synchrone Schreibvorgänge (normalerweise aufgrund von Journalling, insbesondere mit ext3 im data = journal-Modus). Darüber hinaus beeinträchtigen selbst "Hintergrund" -Seitenlöschvorgänge nicht zwischengespeicherte Lesevorgänge und synchrones Schreiben und verlangsamen sie so.

Im Allgemeinen sollten Sie einige Kennzahlen verwenden, um zu überprüfen, was gerade passiert. Wird der Kopiervorgang im Status "D" angezeigt, während auf die Ausführung der E / A-Arbeit durch pdflush gewartet wird? Sehen Sie starke synchrone Schreibaktivitäten auf Ihren Datenträgern?

Wenn alles andere fehlschlägt, können Sie ein explizites tmpfs-Dateisystem einrichten, in das Sie Ihre Backups kopieren und anschließend nur noch Daten mit Ihren Festplatten synchronisieren - auch automatisch mit inotify

Für das Lesen im Cache sind die Dinge wesentlich einfacher - es gibt das fadviseDienstprogramm fcoretools, das den --willneedParameter hat, der den Kernel anweist, den Inhalt der Datei in den Puffer-Cache zu laden.

Bearbeiten:

vm.dirty_ratio = 70

Dies sollte uns theoretisch 16 GB für das Zwischenspeichern von E / A geben und einige Minuten warten, bis es auf die Festplatte geschrieben wird.

Dies hätte Ihr Testszenario nicht wesentlich beeinflusst, aber es gibt ein Missverständnis in Ihrem Verständnis. Der Parameter dirty_ratio gibt nicht einen Prozentsatz des Gesamtspeichers Ihres Systems an, sondern den freien Speicher Ihres Systems .

Es gibt einen Artikel über die Optimierung für schreiblastige Lasten mit detaillierteren Informationen.

— das-wabbit
quelle

Ja, ich bin nach Schreibperformance. Die Zeit, die benötigt wird, um das Backup auf die Backup-Slaves aufzufächern, ist keine meiner Sorgen. Ich habe auch ein Skript für die erneute Übertragung eingerichtet, falls der primäre Backup-Server ausfällt und die Backups nicht an die Backup-Slaves gelangen. PS Ich habe den Link schon gelesen und entsprechend abgestimmt. Entschuldigen Sie den Fehler zwischen kostenlos und gepuffert und insgesamt.

— Peter Meyer

Oder holen Sie sich einfach mehr Festplatten ... Die Laufwerk-Array-Konfiguration, die Sie haben, unterstützt nicht die gesamte erforderliche Konfiguration. In diesem Fall sollte die Lösung Ihren tatsächlichen Anforderungen entsprechend überarbeitet werden. Ich verstehe, dass dies nur ein Backup ist, aber es ist sinnvoll, eine klobige Lösung zu vermeiden.

— ewwhite
quelle

Einverstanden. Es gibt keine Möglichkeit, dass einige SATA- Laufwerke ( SATA ? Im Ernst?) 275 MB / s unterstützen, und wir sprechen nicht einmal über die abgründigen IOPs, die Sie von ihnen erhalten.

— 15.

Ich kann sehen, wohin er unterwegs ist - da dies nur ein Ziel für die Datensicherung ist, ist ihm die Möglichkeit eines gelegentlichen Datenverlusts aufgrund von Stromausfällen egal. Und er möchte den Zeitaufwand für ein Backup-Fenster minimieren, indem er den maximal verfügbaren Durchsatz bereitstellt. Auf diese Weise könnten 20 GB Daten in weniger als 30 Sekunden geschrieben werden. Wenn die Backups aus irgendeinem Grund Ausfallzeiten oder Auswirkungen auf den Service haben, sind 30 Sekunden mit Sicherheit einfacher als 20 Minuten.

— The-Wabbit

Völlig richtig. Ich synchronisiere Images von virtuellen Maschinen (sehr kleine für Rechenknoten), die während der Synchronisierung nicht verfügbar sind. Die App funktioniert wie tar | ssh aber mit ftp. Und nun, die Simulationen müssen laufen ... :)

— Peter Meyer

Es ist egal, um welche SATA-Rasse es sich handelt. Nicht-Enterprise-Festplatten mit 7200 U / min können einfach keinen Durchsatz oder keine Latenz garantieren.

— adaptr

@adaptr, ein Backup besteht aus sequentiellen Schreibvorgängen.

— Psusi

Die Verwendung des Cache-Speichers kann zu Datenverlusten führen, da Daten, die sich im Speicher befinden und nicht auf Datenträgern gespeichert sind, verloren gehen, wenn ein Fehler auftritt.

Das heißt, es gibt Abstimmungen auf Dateisystemebene.

Wenn Sie beispielsweise ext4 verwenden, können Sie die Mount-Option verwenden:

Barriere = 0

Das: "Deaktiviert die Verwendung von Schreibbarrieren im jbd-Code. Schreibbarrieren erzwingen die ordnungsgemäße Anordnung von Journal-Commits auf der Festplatte, wodurch Schreibcaches für flüchtige Datenträger sicher und mit gewissen Leistungseinbußen verwendet werden können. Wenn Ihre Datenträger auf eine Weise batteriegepuffert sind Zum anderen kann das Deaktivieren von Barrieren die Leistung sicher verbessern. Die Mount-Optionen "barrier" und "nobarrier" können auch zum Aktivieren oder Deaktivieren von Barrieren verwendet werden, um die Konsistenz mit anderen ext4-Mount-Optionen zu gewährleisten. "

Mehr unter: http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt

— Peter Senna
quelle

Ich verwende ein stark abgestimmtes XFS. Mehr dazu im obigen Kommentar :)

— Peter Meyer

Das Dateisystem wurde mit mkfs.xfs -l lazy-count = 1, Version = 2, Größe = 256 m -i attr = 2 -d sunit = 512, swidth = 1024 erstellt und wird eingehängt mit: rw, noatime, logbufs = 8, logbsize = 256k, osyncisdsync, delaylog, attr2, nobarrier, allocsize = 256k

— Peter Meyer