it-swarm.com.de

Kann ich mein Linux-System für aggressiveres Dateisystem-Caching konfigurieren?

Ich mache mir weder Sorgen um die Verwendung von RAM) (da ich genug habe) noch um den Verlust von Daten im Falle eines versehentlichen Herunterfahrens (da meine Stromversorgung gesichert ist, ist das System zuverlässig und die Daten sind nicht kritisch). 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 Lese- und Schreib-Caching des Dateisystems) verwendet wird, um Dateien aggressiv vorab abzurufen (z. B. das Vorlesen der gesamten Datei, auf die eine Anwendung zugreift, falls Die Datei hat eine vernünftige Größe oder liest ansonsten zumindest einen großen Teil davon vor) und um Schreibpuffer weniger häufig zu leeren. Wie kann dies erreicht werden (ist dies möglich)?

Ich verwende ext3- und ntfs-Dateisysteme (ich verwende häufig ntfs!) Mit XUbuntu 11.10 x86.

124
Ivan

Das Verbessern der Festplatten-Cache-Leistung im Allgemeinen ist mehr als nur das Erhöhen der Cache-Größe des Dateisystems, es sei denn, Ihr gesamtes System passt in RAM. In diesem Fall sollten Sie das Laufwerk RAM verwenden (tmpfs ist gut, da es ermöglicht, auf die Festplatte zurückzugreifen, wenn Sie in einigen Fällen RAM benötigen), um zur Laufzeit zu speichern (und möglicherweise ein initrd-Skript, um das System vom Speicher in RAM Laufwerk beim Start).

Sie haben nicht festgestellt, ob es sich bei Ihrem Speichergerät um eine SSD oder eine Festplatte handelt. Ich habe festgestellt, dass dies für mich funktioniert (in meinem Fall ist sda eine Festplatte, die unter /home Und sdb unter / Bereitgestellt ist).

Optimieren Sie zuerst den Teil zum Laden von Sachen aus dem Speicher in den Cache:

Hier ist mein Setup für die Festplatte (stellen Sie sicher, dass AHCI + NCQ im BIOS aktiviert ist, wenn Sie umschalten müssen):

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 hoch fifo_expire_async (Normalerweise schreiben) und lang slice_sync, Damit ein einzelner Prozess einen hohen Durchsatz erzielen kann (setzen Sie slice_sync Auf eine niedrigere Zahl, wenn Sie auf Situationen stoßen wo mehrere Prozesse parallel auf einige Daten von der Festplatte warten). Der slice_idle Ist immer ein Kompromiss für Festplatten, aber je nach Festplattennutzung und Festplattenfirmware sollte es in Ordnung sein, ihn irgendwo im Bereich von 3 bis 20 einzustellen. Ich ziehe es vor, niedrige Werte anzustreben, aber wenn Sie sie zu niedrig einstellen, wird Ihr Durchsatz zerstört. Die Einstellung quantum scheint den Durchsatz stark zu beeinflussen, aber versuchen Sie, dies so gering wie möglich zu halten, um die Latenz auf einem vernünftigen Niveau zu halten. Wenn Sie quantum zu niedrig einstellen, wird der Durchsatz zerstört. Werte im Bereich von 3 bis 8 scheinen mit Festplatten gut zu funktionieren. Die Latenz im ungünstigsten Fall für einen Lesevorgang ist (quantum * slice_sync) + (slice_async_rq * slice_async) Ms, wenn ich das Kernelverhalten richtig verstanden habe. Der Async wird hauptsächlich von Schreibvorgängen verwendet. Da Sie das Schreiben auf die Festplatte verzögern möchten, setzen Sie sowohl slice_async_rq Als auch slice_async Auf sehr niedrige Zahlen. Wenn Sie jedoch slice_async_rq Zu niedrig einstellen, werden die Lesevorgänge möglicherweise blockiert, da Schreibvorgänge nach dem Lesen nicht mehr verzögert werden können. Meine Konfiguration wird versuchen, Daten spätestens 10 Sekunden nach der Datenübergabe an den Kernel auf die Festplatte zu schreiben. Da Sie jedoch Datenverluste bei Stromausfall tolerieren können, setzen Sie fifo_expire_async Auf 3600000, Um dies zu bestätigen 1 Stunde ist in Ordnung für die Verzögerung der Festplatte. Halten Sie jedoch einfach slice_async Niedrig, da Sie sonst eine hohe Leselatenz erhalten können.

Der Befehl hdparm ist erforderlich, um zu verhindern, dass AAM einen Großteil der von AHCI + NCQ zugelassenen Leistung beeinträchtigt. Wenn Ihre Festplatte zu laut ist, überspringen Sie diese.

Hier ist mein Setup für SSD (Intel 320-Serie):

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 den Wert auf Null setzen, werden alle Bestellentscheidungen in die native NCQ verschoben, während Sie ihn auf 1 setzen, damit der Kernel Anforderungen bestellen kann. Wenn die NCQ jedoch aktiv ist, kann die Hardware die Kernelreihenfolge teilweise überschreiben. Testen Sie beide Werte, um festzustellen, ob Sie den Unterschied erkennen können. Bei der Intel 320-Serie scheint die Einstellung von slide_idle Auf 0 Den besten Durchsatz zu erzielen, die Einstellung auf 1 Die beste (niedrigste) Gesamtlatenz.

Weitere Informationen zu diesen Tunables finden Sie unter https://www.kernel.org/doc/Documentation/block/cfq-iosched.txt .

Nachdem wir den Kernel so konfiguriert haben, dass Inhalte mit vernünftiger Leistung von der Festplatte in den Cache geladen werden, ist es an der Zeit, das Cache-Verhalten anzupassen:

Nach den Benchmarks, die ich durchgeführt habe, würde ich das Lesen über blockdev überhaupt nicht einstellen. Die Standardeinstellungen des Kernels sind in Ordnung.

Stellen Sie das System so ein, dass das Austauschen von Dateidaten gegenüber dem Anwendungscode bevorzugt wird (dies spielt keine Rolle, wenn Sie über genügend RAM verfügen, um gesamtes Dateisystem nd den gesamten Anwendungscode beizubehalten - nd der gesamte virtuelle Speicher, der von Anwendungen im RAM zugewiesen wird). Dies reduziert die Latenz für den Austausch zwischen verschiedenen Anwendungen gegenüber der Latenz für den Zugriff auf große Dateien von einer einzigen Anwendung aus:

echo 15 > /proc/sys/vm/swappiness

Wenn Sie es vorziehen, Anwendungen fast immer in RAM zu belassen, können Sie dies auf 1 setzen. Wenn Sie dies auf Null setzen, wird der Kernel überhaupt nicht ausgetauscht, es sei denn, dies ist unbedingt erforderlich, um OOM zu vermeiden. Wenn Sie nur über begrenzten Speicher verfügen und mit großen Dateien arbeiten (z. B. HD-Videobearbeitung), ist es möglicherweise sinnvoll, diesen Wert auf 100 zu setzen.

Ich bevorzuge heutzutage (2017), überhaupt keinen Swap zu haben, wenn Sie genug RAM haben. Wenn Sie keinen Swap haben, verlieren Sie normalerweise 200-1000 MB RAM auf einem Desktop-Computer mit langer Laufzeit. Ich bin bereit, so viel zu opfern, um die Latenz im schlimmsten Fall zu vermeiden (Anwendungscode austauschen, wenn RAM voll ist). In der Praxis bedeutet dies, dass ich OOM Killer dem Tauschen vorziehe. Wenn Sie das Austauschen zulassen/benötigen, möchten Sie möglicherweise auch /proc/sys/vm/watermark_scale_factor Erhöhen, um eine gewisse Latenz zu vermeiden. Ich würde Werte zwischen 100 und 500 vorschlagen. Sie können diese Einstellung als Handel mit CPU-Auslastung gegen geringere Swap-Latenz betrachten. Der Standardwert ist 10 und das maximal mögliche ist 1000. Ein höherer Wert sollte (gemäß Kerneldokumentation ) zu einer höheren CPU-Auslastung für kswapd -Prozesse und einer geringeren Gesamtlatenz beim Austauschen führen.

Weisen Sie den Kernel als Nächstes an, die Verzeichnishierarchie lieber im Speicher als den Dateiinhalt beizubehalten, falls RAM freigegeben werden muss (wenn alles in den RAM passt, führt diese Einstellung nichts aus):

echo 10 > /proc/sys/vm/vfs_cache_pressure

Das Setzen 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. Wenn der Verzeichniscache zu früh geleert wird, ist der Dateicache nahezu wertlos. Wenn Sie viele kleine Dateien haben, sollten Sie bei dieser Einstellung bis auf 1 gehen (mein System verfügt über ca. 150 KByte 10-Megapixel-Fotos und zählt als System "viele kleine Dateien"). Setzen Sie es niemals auf Null, oder die Verzeichnisstruktur bleibt immer im Speicher, auch wenn dem System der Speicher ausgeht. Das Festlegen eines großen Werts ist nur dann sinnvoll, wenn Sie nur wenige große Dateien haben, die ständig neu gelesen werden (auch hier wäre die HD-Videobearbeitung ohne genügend RAM ein Beispiel). Die offizielle Kerneldokumentation besagt, dass "eine signifikante Erhöhung von vfs_cache_pressure über 100 hinaus negative Auswirkungen auf die Leistung haben kann".

Ausnahme: wenn Sie wirklich viele Dateien und Verzeichnisse haben und selten alle Dateien berühren/lesen/auflisten, wobei vfs_cache_pressure Höher als 100 ist kann weise sein. Dies gilt nur, wenn Sie nicht über genügend RAM verfügen und nicht die gesamte Verzeichnisstruktur in RAM behalten können und dennoch über genügend RAM für den normalen Dateicache und die normalen Prozesse (z. B. Firma) verfügen breiter Dateiserver mit viel Archivinhalt). Wenn Sie der Meinung sind, dass Sie vfs_cache_pressure Über 100 erhöhen müssen, haben Sie nicht genügend RAM. Das Erhöhen von vfs_cache_pressure Kann helfen, aber die einzige wirkliche Lösung besteht darin, mehr RAM zu erhalten. Wenn vfs_cache_pressure Auf eine hohe Anzahl eingestellt ist, wird die durchschnittliche Leistung für eine insgesamt stabilere Leistung beeinträchtigt (dh Sie können ein wirklich schlechtes Worst-Case-Verhalten vermeiden, müssen sich jedoch mit einer schlechteren Gesamtleistung auseinandersetzen).

Weisen Sie den Kernel schließlich 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 Sie den Schreibvorgang verlangsamen (Standard für dirty_background_ratio Ist 10). Warnung: Ich persönlich würde dies nicht tun, aber Sie haben behauptet, genug RAM zu haben und sind bereit, die Daten zu verlieren.

echo 99 > /proc/sys/vm/dirty_ratio
echo 50 > /proc/sys/vm/dirty_background_ratio

Und sag, dass eine Schreibverzögerung von 1 Stunde in Ordnung ist, um start ​​Sachen auf die Festplatte zu schreiben (wieder 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 alle auf /etc/rc.local Setzen und am Ende Folgendes einfügen, wird alles so schnell wie möglich nach dem Start im Cache gespeichert (tun Sie dies nur, wenn Ihr Dateisystem wirklich in den RAM 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 möglicherweise besser funktioniert (nur Cache /home Und /usr, Tun Sie dies nur, wenn Ihre /home Und /usr Wirklich in den RAM passen):

(Nice find /home /usr -type f -print0 | Nice ionice -c 3 wc -l --files0-from - > /dev/null)&
113

Erstens empfehle ich NICHT, NTFS weiterhin zu verwenden, da die Implementierung von ntfs unter Linux jederzeit zu Leistungs- und Sicherheitsproblemen führen würde.

Sie können verschiedene Dinge tun:

  • benutze einige neuere fs wie ext4 oder btrfs
  • versuchen Sie, Ihren Io-Scheduler zu ändern, zum Beispiel bfq
  • swap ausschalten
  • verwenden Sie einen automatischen Preloader wie preload
  • verwenden Sie etwas wie systemd, um beim Booten vorzuladen
  • ... und noch etwas mehr

Vielleicht möchten Sie es versuchen :-)

16
Felix Yan

Lesen Sie weiter:

Auf 32-Bit-Systemen:

blockdev --setra 8388607 /dev/sda

Auf 64-Bit-Systemen:

blockdev --setra 4294967295 /dev/sda

Schreiben Sie hinter den Cache:

echo 100 > /proc/sys/vm/dirty_ratio

Dadurch werden bis zu 100% Ihres freien Speichers als Schreibcache verwendet.

Oder Sie können alles daran setzen, tmpfs zu verwenden. Dies ist nur relevant, wenn Sie RAM genug. Geben Sie dies in /etc/fstab. Ersetzen Sie 100 GB durch den physischen RAM.

tmpfs /mnt/tmpfs tmpfs size=100G,rw,nosuid,nodev 0 0

Dann:

mkdir /mnt/tmpfs; mount -a

Verwenden Sie dann/mnt/tmpfs.

8
Ole Tange

Sie können die Vorauslesegröße mit blockdev --setra sectors /dev/sda1 Festlegen, wobei Sektoren die gewünschte Größe in 512-Byte-Sektoren sind.

6
psusi

Meine Killereinstellung ist sehr einfach und sehr effektiv:

echo "2000" > /proc/sys/vm/vfs_cache_pressure

Die Erklärung von Kerneldokumentation :

vfs_cache_pressure

Steuert die Tendenz des Kernels, den Speicher zurückzugewinnen, der zum Zwischenspeichern von Verzeichnis- und Inode-Objekten verwendet wird.

Beim Standardwert von vfs_cache_pressure = 100 versucht der Kernel, Einträge und Inodes mit einer "fairen" Rate in Bezug auf die Seiten- und Swapcache-Rückforderung zurückzugewinnen. Wenn Sie vfs_cache_pressure verringern, zieht der Kernel es vor, Dentry- und Inode-Caches beizubehalten. Wenn vfs_cache_pressure = 0 ist, fordert der Kernel aufgrund des Speicherdrucks niemals Dentries und Inodes zurück. Dies kann leicht zu Speichermangel führen. Wenn Sie vfs_cache_pressure auf über 100 erhöhen, zieht der Kernel es vor, Dentries und Inodes zurückzugewinnen.

vfs_cache_pressure bei 2000 führt dazu, dass der größte Teil der Datenverarbeitung im RAM und sehr späten Festplattenschreibvorgängen) stattfindet.

2
user55518

Nicht im Zusammenhang mit dem Zwischenspeichern von Schreibvorgängen, sondern im Zusammenhang mit Schreibvorgängen:

  • Für ein ext4-System könnten Sie Journaling vollständig deaktivieren

    Dies reduziert die Anzahl der Festplattenschreibvorgänge für ein bestimmtes Update, kann jedoch dazu führen, dass das Dateisystem nach einem unerwarteten Herunterfahren einen inkonsistenten Zustand aufweist, der ein fsck oder schlechter erfordert.

So verhindern Sie, dass Festplattenlesevorgänge Festplattenschreibvorgänge auslösen:

  • Mounten Sie mit der Option relatime oder noatime

    Wenn Sie eine Datei lesen, werden die Metadaten für die letzte Zugriffszeit für diese Datei normalerweise aktualisiert. Die Option noatime deaktiviert dieses Verhalten. Dies reduziert unnötige Festplattenschreibvorgänge, aber Sie haben diese Metadaten nicht mehr. Einige Distributionen (z. B. Manjaro) haben dies als Standard für alle Partitionen übernommen (wahrscheinlich, um die Lebensdauer früherer SSD-Modelle zu verlängern).

    relatime aktualisiert die Zugriffszeit weniger häufig gemäß Heuristiken, die zur Unterstützung von Anwendungen beitragen, die den atime verwenden. Dies ist die Standardeinstellung unter Red Hat Enterprise Linux.

Andere Optionen:

  • In den obigen Kommentaren teilte Mikko die Möglichkeit der Montage mit der Option nobarrier . Aber Ivailo zitiert RedHat wer warnt davor. Wie sehr wollen Sie diese zusätzlichen 3%?
1
joeytwiddle