Ich mache mir weder Sorgen über die RAM-Nutzung (da ich genug habe) noch über den Verlust von Daten im Falle eines versehentlichen Herunterfahrens (da meine Stromversorgung gesichert ist, das System zuverlässig ist und die Daten nicht kritisch sind). Aber ich mache viel Dateiverarbeitung und könnte eine Leistungssteigerung gebrauchen.
Aus diesem Grund möchte ich das System so einrichten, dass mehr RAM für das Lesen und Schreiben des Dateisystems zwischengespeichert wird, um Dateien aggressiv vorzuladen (z andernfalls einen großen Teil davon vorauslesen) und Schreibpuffer weniger häufig zu leeren. Wie erreicht man das (möglicherweise)?
Ich verwende ext3- und ntfs-Dateisysteme (ich verwende ntfs häufig!) mit XUbuntu 11.10 x86.
Akzeptierte Antwort:
Das Verbessern der Festplatten-Cache-Leistung im Allgemeinen ist mehr als nur das Erhöhen der Dateisystem-Cache-Größe, es sei denn, Ihr ganzes System passt in RAM, in diesem Fall sollten Sie das RAM-Laufwerk verwenden (tmpfs ist gut, weil es einen Rückgriff auf die Festplatte ermöglicht, wenn Sie in einigen Fällen RAM benötigen) für die Laufzeitspeicherung (und vielleicht ein initrd-Skript, um das System beim Start vom Speicher auf das RAM-Laufwerk zu kopieren).
Sie haben nicht gesagt, ob Ihr Speichergerät SSD oder HDD ist. Hier ist, was ich gefunden habe, um für mich zu arbeiten (in meinem Fall sda ist eine Festplatte, die unter /home gemountet ist und sdb ist SSD unter / gemountet ).
Optimieren Sie zuerst den Teil zum Laden von Inhalten aus dem Speicher in den Cache:
Hier ist mein Setup für HDD (stellen Sie sicher, dass AHCI+NCQ im BIOS aktiviert ist, wenn Sie Umschalter haben):
echo cfq > /sys/block/sda/queue/scheduler
echo 10000 > /sys/block/sda/queue/iosched/fifo_expire_async
echo 250 > /sys/block/sda/queue/iosched/fifo_expire_sync
echo 80 > /sys/block/sda/queue/iosched/slice_async
echo 1 > /sys/block/sda/queue/iosched/low_latency
echo 6 > /sys/block/sda/queue/iosched/quantum
echo 5 > /sys/block/sda/queue/iosched/slice_async_rq
echo 3 > /sys/block/sda/queue/iosched/slice_idle
echo 100 > /sys/block/sda/queue/iosched/slice_sync
hdparm -q -M 254 /dev/sda
Bemerkenswert für den HDD-Fall ist der hohe fifo_expire_async (normalerweise schreiben) und langes slice_sync um einem einzelnen Prozess einen hohen Durchsatz zu ermöglichen (setzen Sie slice_sync auf eine niedrigere Zahl, wenn Sie auf Situationen stoßen, in denen mehrere Prozesse parallel auf einige Daten von der Festplatte warten). Der slice_idle ist immer ein Kompromiss für HDDs, aber eine Einstellung irgendwo im Bereich 3-20 sollte je nach Festplattennutzung und Festplattenfirmware in Ordnung sein. Ich ziehe es vor, auf niedrige Werte zu zielen, aber wenn Sie sie zu niedrig einstellen, wird Ihr Durchsatz zerstört. Das quantum Die Einstellung scheint den Durchsatz stark zu beeinflussen, aber versuchen Sie, diesen so gering wie möglich zu halten, um die Latenz auf einem vernünftigen Niveau zu halten. quantum einstellen zu niedrig wird den Durchsatz zerstören. Werte im Bereich von 3-8 scheinen mit HDDs gut zu funktionieren. Die Worst-Case-Latenz für einen Lesevorgang beträgt (quantum * slice_sync ) + (slice_async_rq * slice_async ) ms, wenn ich das Kernel-Verhalten richtig verstanden habe. Die Asynchronität wird hauptsächlich von Schreibvorgängen verwendet, und da Sie bereit sind, das Schreiben auf die Festplatte zu verzögern, setzen Sie beide slice_async_rq und slice_async auf sehr niedrige Zahlen. Setzen Sie jedoch slice_async_rq Ein zu niedriger Wert kann Lesevorgänge blockieren, da Schreibvorgänge nach Lesevorgängen nicht mehr verzögert werden können. Meine Konfiguration versucht spätestens nach 10 Sekunden, nachdem die Daten an den Kernel übergeben wurden, Daten auf die Festplatte zu schreiben, aber da Sie einen Datenverlust bei einem Stromausfall tolerieren können, setzen Sie auch fifo_expire_async bis 3600000 zu sagen, dass 1 Stunde für die Verzögerung auf der Festplatte in Ordnung ist. Behalten Sie einfach slice_async bei niedrig, da Sie sonst eine hohe Leselatenz erhalten können.
Die hdparm Der Befehl ist erforderlich, um zu verhindern, dass AAM einen Großteil der Leistung beeinträchtigt, die AHCI + NCQ ermöglicht. Wenn Ihre Festplatte zu viel Lärm macht, überspringen Sie dies.
Hier ist mein Setup für SSD (Intel 320-Reihe):
echo cfq > /sys/block/sdb/queue/scheduler
echo 1 > /sys/block/sdb/queue/iosched/back_seek_penalty
echo 10000 > /sys/block/sdb/queue/iosched/fifo_expire_async
echo 20 > /sys/block/sdb/queue/iosched/fifo_expire_sync
echo 1 > /sys/block/sdb/queue/iosched/low_latency
echo 6 > /sys/block/sdb/queue/iosched/quantum
echo 2 > /sys/block/sdb/queue/iosched/slice_async
echo 10 > /sys/block/sdb/queue/iosched/slice_async_rq
echo 1 > /sys/block/sdb/queue/iosched/slice_idle
echo 20 > /sys/block/sdb/queue/iosched/slice_sync
Hier sind die niedrigen Werte für verschiedene Slice-Einstellungen zu beachten. Die wichtigste Einstellung für eine SSD ist slice_idle die auf 0-1 gesetzt werden muss. Wenn Sie es auf null setzen, werden alle Sortierentscheidungen zum nativen NCQ verschoben, während es auf 1 gesetzt wird, dass der Kernel Anforderungen ordnen kann (aber wenn der NCQ aktiv ist, kann die Hardware die Kernel-Reihenfolge teilweise überschreiben). Testen Sie beide Werte, um zu sehen, ob Sie den Unterschied sehen können. Für die Intel 320-Serie scheint die Einstellung slide_idle zu ergibt den besten Durchsatz, wenn Sie ihn jedoch auf 1 setzen ergibt die beste (niedrigste) Gesamtlatenz.
Weitere Informationen zu diesen Tunables finden Sie unter https://www.kernel.org/doc/Documentation/block/cfq-iosched.txt .
Update im Jahr 2020 und Kernel-Version 5.3 (cfq ist tot):
modprobe bfq
for d in /sys/block/sd?
do
# HDD (tuned for Seagate SMR drive)
echo bfq > "$d/queue/scheduler"
echo 4 > "$d/queue/nr_requests"
echo 32000 > "$d/queue/iosched/back_seek_max"
echo 3 > "$d/queue/iosched/back_seek_penalty"
echo 80 > "$d/queue/iosched/fifo_expire_sync"
echo 1000 > "$d/queue/iosched/fifo_expire_async"
echo 5300 > "$d/queue/iosched/slice_idle_us"
echo 1 > "$d/queue/iosched/low_latency"
echo 200 > "$d/queue/iosched/timeout_sync"
echo 0 > "$d/queue/iosched/max_budget"
echo 1 > "$d/queue/iosched/strict_guarantees"
# additional tweaks for SSD (tuned for Samsung EVO 850):
if test $(cat "$d/queue/rotational") = "0"
then
echo 36 > "$d/queue/nr_requests"
echo 1 > "$d/queue/iosched/back_seek_penalty"
# slice_idle_us should be ~ 0.7/IOPS in µs
echo 16 > "$d/queue/iosched/slice_idle_us"
echo 10 > "$d/queue/iosched/fifo_expire_sync"
echo 250 > "$d/queue/iosched/fifo_expire_async"
echo 10 > "$d/queue/iosched/timeout_sync"
echo 0 > "$d/queue/iosched/strict_guarantees"
fi
done
Das Setup ist ziemlich ähnlich, aber ich verwende jetzt bfq statt cfq weil letzteres mit modernen Kerneln nicht verfügbar ist. Ich versuche nr_requests zu behalten so niedrig wie möglich, um bfq zu ermöglichen um die Zeitplanung genauer zu steuern. Zumindest Samsung SSD-Laufwerke scheinen eine ziemlich lange Warteschlange zu benötigen, um mit hohen IOPS laufen zu können.
Ich verwende Ubuntu 18.04 mit dem Kernelpaket linux-lowlatency-hwe-18.04-edge das hat bfq nur als Modul, also muss ich es laden, bevor ich darauf umschalten kann.
Ich benutze auch heutzutage zram aber ich benutze nur 5% des RAMs für zram. Dadurch kann der Linux-Kernel die Swapping-bezogene Logik verwenden, ohne die Festplatten zu berühren. Wenn Sie sich jedoch für Zero Disk Swap entscheiden, stellen Sie sicher, dass Ihre Apps kein RAM verlieren oder Sie Geld verschwenden.
Jetzt, da wir den Kernel so konfiguriert haben, dass er Sachen mit angemessener Leistung von der Festplatte in den Cache lädt, ist es an der Zeit, das Cache-Verhalten anzupassen:
Laut Benchmarks, die ich durchgeführt habe, würde ich mir nicht die Mühe machen, Vorauslesen über blockdev einzustellen überhaupt. Kernel-Standardeinstellungen sind in Ordnung.
Stellen Sie das System so ein, dass Dateidaten dem Anwendungscode vorgezogen werden (dies spielt keine Rolle, wenn Sie genügend RAM haben, um vollständig zu bleiben Dateisystem und den gesamten Anwendungscode und allen virtuellen Speicher, der von Anwendungen im RAM zugewiesen wird). Dies reduziert die Latenz beim Wechseln zwischen verschiedenen Anwendungen gegenüber der Latenz beim Zugriff auf große Dateien aus einer einzelnen Anwendung:
echo 15 > /proc/sys/vm/swappiness
Wenn Sie es vorziehen, Anwendungen fast immer im RAM zu behalten, können Sie dies auf 1 setzen. Wenn Sie dies auf Null setzen, wird der Kernel überhaupt nicht auslagern, es sei denn, dies ist unbedingt erforderlich, um OOM zu vermeiden. Wenn Sie wenig Speicherplatz haben und mit großen Dateien arbeiten (z. B. HD-Videobearbeitung), kann es sinnvoll sein, diesen Wert auf etwa 100 einzustellen.
Ich ziehe es heutzutage (2017) vor, überhaupt keinen Swap zu haben, wenn Sie genug RAM haben. Ohne Swap gehen normalerweise 200-1000 MB RAM auf Desktop-Rechnern mit langer Laufzeit verloren. Ich bin bereit, so viel zu opfern, um die Latenz des Worst-Case-Szenarios zu vermeiden (Anwendungscode austauschen, wenn der RAM voll ist). In der Praxis bedeutet das, dass ich OOM Killer dem Tauschen vorziehe. Wenn Sie das Austauschen zulassen/müssen, sollten Sie /proc/sys/vm/watermark_scale_factor erhöhen , um Latenzen zu vermeiden. Ich würde Werte zwischen 100 und 500 vorschlagen. Sie können diese Einstellung als Tausch der CPU-Auslastung für eine geringere Swap-Latenzzeit betrachten. Der Standardwert ist 10 und der maximal mögliche Wert ist 1000. Ein höherer Wert sollte (laut Kernel-Dokumentation) zu einer höheren CPU-Auslastung für kswapd führen Prozesse und niedrigere Gesamt-Swapping-Latenzzeit.
Als nächstes teilen Sie dem Kernel mit, dass er lieber die Verzeichnishierarchie im Speicher behalten soll als den Dateiinhalt, falls etwas RAM freigegeben werden muss (wieder, wenn alles in den RAM passt, tut diese Einstellung nichts):
echo 10 > /proc/sys/vm/vfs_cache_pressure
Einstellen von vfs_cache_pressure auf einen niedrigen Wert ist sinnvoll, da der Kernel in den meisten Fällen die Verzeichnisstruktur kennen muss, bevor er Dateiinhalte aus dem Cache verwenden kann, und ein zu frühes Leeren des Verzeichniscaches den Dateicache nahezu wertlos macht. Erwägen Sie, mit dieser Einstellung ganz nach unten auf 1 zu gehen, wenn Sie viele kleine Dateien haben (mein System hat etwa 150.000 10-Megapixel-Fotos und zählt als System mit „vielen kleinen Dateien“). Setzen Sie es niemals auf Null oder die Verzeichnisstruktur wird immer im Speicher gehalten, auch wenn dem System der Speicher ausgeht. Die Einstellung auf einen großen Wert ist nur sinnvoll, wenn Sie nur wenige große Dateien haben, die ständig neu eingelesen werden (wiederum wäre HD-Videobearbeitung ohne genügend RAM ein Beispielfall). Die offizielle Kernel-Dokumentation besagt, dass „eine deutliche Erhöhung von vfs_cache_pressure über 100 negative Auswirkungen auf die Leistung haben kann“.
Ausnahme: Wenn Sie wirklich eine riesige Menge an Dateien und Verzeichnissen haben und selten alle Dateien berühren/lesen/auflisten, setzen Sie vfs_cache_pressure höher als 100 kann sinnvoll sein. Dies gilt nur, wenn Sie nicht über genügend RAM verfügen und nicht die gesamte Verzeichnisstruktur im RAM halten können und dennoch genügend RAM für normale Datei-Cache und -Prozesse haben (z. B. unternehmensweiter Dateiserver mit vielen Archivinhalten). Wenn Sie das Gefühl haben, dass Sie vfs_cache_pressure erhöhen müssen über 100 laufen Sie ohne genügend RAM. Erhöhen von vfs_cache_pressure kann helfen, aber die einzige wirkliche Lösung ist, mehr RAM zu bekommen. vfs_cache_pressure haben Die Einstellung auf eine hohe Zahl opfert die durchschnittliche Leistung zugunsten einer stabileren Gesamtleistung (das heißt, Sie können ein wirklich schlechtes Worst-Case-Verhalten vermeiden, müssen sich aber mit einer schlechteren Gesamtleistung auseinandersetzen).
Weisen Sie schließlich den Kernel an, bis zu 99 % des RAM als Cache für Schreibvorgänge zu verwenden, und weisen Sie den Kernel an, bis zu 50 % des RAM zu verwenden, bevor der schreibende Prozess verlangsamt wird (Standard für dirty_background_ratio). ist 10 ). Warnung:Ich persönlich würde dies nicht tun, aber Sie haben behauptet, dass Sie über genügend RAM verfügen und bereit sind, die Daten zu verlieren.
echo 99 > /proc/sys/vm/dirty_ratio
echo 50 > /proc/sys/vm/dirty_background_ratio
Und sagen Sie, dass 1 Stunde Schreibverzögerung in Ordnung ist, um überhaupt zu starten Sachen auf die Platte schreiben (wiederum würde ich das nicht tun):
echo 360000 > /proc/sys/vm/dirty_expire_centisecs
echo 360000 > /proc/sys/vm/dirty_writeback_centisecs
Weitere Informationen zu diesen Tunables finden Sie unter https://www.kernel.org/doc/Documentation/sysctl/vm.txt
Wenn Sie all diese in /etc/rc.local ablegen und am Ende folgendes einfügen, alles wird so schnell wie möglich nach dem Booten im Cache sein (nur tun, wenn Ihr Dateisystem wirklich in den Arbeitsspeicher passt):
(nice find / -type f -and -not -path '/sys/*' -and -not -path '/proc/*' -print0 2>/dev/null | nice ionice -c 3 wc -l --files0-from - > /dev/null)&
Oder eine etwas einfachere Alternative, die besser funktionieren könnte (cache nur /home und /usr , tun Sie dies nur, wenn Ihr /home und /usr wirklich in RAM passen):
(nice find /home /usr -type f -print0 | nice ionice -c 3 wc -l --files0-from - > /dev/null)&