Wann sollte ich /dev/shm/ verwenden und wann sollte ich /tmp/?

Neuere 2.6-Linux-Kernel-Builds haben damit begonnen, /dev/shm als gemeinsam genutzten Speicher in Form einer Ramdisk anzubieten, genauer gesagt als ein Verzeichnis, das von allen beschreibbar ist und im Speicher mit einem definierten Limit in /etc/default/tmpfs gespeichert wird. /dev/shm-Unterstützung ist innerhalb der Kernel-Konfigurationsdatei vollständig optional. Es ist standardmäßig sowohl in Fedora- als auch in Ubuntu-Distributionen enthalten, wo es am häufigsten von der Pulsaudio-Anwendung verwendet wird.

/tmp ist der Speicherort für temporäre Dateien, wie im Filesystem Hierarchy Standard definiert, dem fast alle Unix- und Linux-Distributionen folgen.

Da RAM wesentlich schneller ist als Festplattenspeicher, können Sie /dev/shm verwenden statt /tmp für die Leistungssteigerung, wenn Ihr Prozess E/A-intensiv ist und ausgiebig temporäre Dateien verwendet.

Um Ihre Fragen zu beantworten:Nein, Sie können sich nicht immer auf /dev/shm verlassen vorhanden sein, schon gar nicht auf gedächtnisarmen Maschinen. Sie sollten /tmp verwenden es sei denn, Sie haben einen sehr guten Grund für die Verwendung von /dev/shm .

Denken Sie daran, dass /tmp kann Teil des / sein Dateisystem anstelle eines separaten Mounts und kann daher nach Bedarf wachsen. Die Größe von /dev/shm wird durch überschüssiges RAM auf dem System begrenzt, und daher ist es wahrscheinlicher, dass Ihnen auf diesem Dateisystem der Speicherplatz ausgeht.

In absteigender Reihenfolge von tmpfs Wahrscheinlichkeit:

┌───────────┬──────────────┬────────────────┐
│ /dev/shm  │ always tmpfs │ Linux specific │
├───────────┼──────────────┼────────────────┤
│ /tmp      │ can be tmpfs │ FHS 1.0        │
├───────────┼──────────────┼────────────────┤
│ /var/tmp  │ never tmpfs  │ FHS 1.0        │
└───────────┴──────────────┴────────────────┘

Da Sie nach einem Linux-spezifischen tmpfs fragen Einhängepunkt im Vergleich zu einem portabel definierten Verzeichnis, das darf tmpfs sein (abhängig von Ihrem Systemadministrator und was für Ihre Distribution voreingestellt ist), hat Ihre Frage zwei Aspekte, die andere Antworten unterschiedlich betont haben:

1. Angemessene Verwendung verschiedener tmp-Verzeichnisse
2. Angemessene Verwendung von tmpfs

Angemessene Verwendung verschiedener tmp-Verzeichnisse

Basierend auf dem alten Filesystem Hierarchy Standard und was Systemd dazu sagt.

• Verwenden Sie im Zweifelsfall /tmp .
• Verwenden Sie /var/tmp für Daten, die über Neustarts hinweg bestehen bleiben sollen.
• Verwenden Sie /var/tmp für große Daten, die nicht ohne weiteres in den RAM passen (vorausgesetzt, dass /var/tmp hat mehr freien Speicherplatz – normalerweise eine faire Annahme).
• Verwenden Sie /dev/shm nur als Nebeneffekt des Aufrufs von shm_open() . Die beabsichtigte Zielgruppe sind begrenzte Puffer, die endlos überschrieben werden. Dies ist also für langlebige Dateien, deren Inhalt flüchtig und nicht besonders groß ist.
• Verwenden Sie auf keinen Fall /dev/shm für ausführbare Dateien (jeglicher Art), da es üblicherweise noexec gemountet wird .
• Wenn Sie immer noch Zweifel haben, bieten Sie dem Benutzer eine Möglichkeit zum Überschreiben. Machen Sie es für die geringste Überraschung wie mktemp und ehre die TMPDIR Umgebungsvariable.

Wo tmpfs sich auszeichnet

Es ist wichtig zu sagen, dass sich tmpfs vor allem darin auszeichnet, einen Leistungsfehler zu verbergen, der auf einer sich drehenden Festplatte von schmerzlicher Bedeutung ist. Wenn also eine Reparatur möglich ist, ist dies natürlich die unangemessene Verwendung von tmpfs :

fsync ist ein No-Op auf tmpfs. Dieser Systemaufruf weist das Betriebssystem an, den mit einer Datei verknüpften Seitencache bis hin zum Leeren des Schreibcaches des entsprechenden Speichergeräts zu leeren, während das Programm, das ihn ausgegeben hat, daran gehindert wird, überhaupt Fortschritte zu machen – eine sehr grobe Schreibbarriere . Es ist nur deshalb ein notwendiges Tool in der Box, weil Speicherprotokolle nicht im Hinblick auf Transaktionen erstellt werden. Und das Caching ist in erster Linie dazu da, es Programmen zu ermöglichen, Millionen von kleinen Schreibvorgängen in eine Datei durchzuführen, ohne zu bemerken, wie langsam es tatsächlich ist, auf ein Speichergerät zu schreiben – das gesamte eigentliche Schreiben erfolgt asynchron oder bis fsync aufgerufen, das ist der einzige Ort, an dem die Schreibleistung direkt vom Programm wahrgenommen wird.

Wenn Sie also feststellen, dass Sie tmpfs (oder eatmydata) verwenden, nur um fsync zu besiegen, dann machen Sie (oder ein anderer Entwickler in der Kette) etwas falsch. Dies bedeutet, dass die Transaktionen zum Speichergerät für Ihren Zweck unnötig feinkörnig sind – Sie sind eindeutig bereit, einige Sicherungspunkte für die Leistung zu überspringen, da Sie jetzt zum Extrem gegangen sind, sie alle zu sabotieren – selten der beste Kompromiss. Außerdem liegen hier im Land der Transaktionsleistung einige der größten Vorteile einer SSD – jede SSD, die ihr Geld wert ist, wird im Vergleich zu dem, was eine sich drehende Festplatte möglicherweise aushalten kann (7200 U/min =120 Hz, wenn sonst nichts darauf zugreift). Flash-Speicherkarten unterscheiden sich auch stark in dieser Metrik (es ist ein Kompromiss mit der sequentiellen Leistung, und die Klasseneinstufung der SD-Karte berücksichtigt nur letztere). Passen Sie also auf, Entwickler mit blitzschnellen SSDs, zwingen Sie Ihre Benutzer nicht zu diesem Anwendungsfall!

Willst du eine lächerliche Geschichte hören? Meine erste fsync Lektion:Ich hatte einen Job, der das routinemäßige "Upgrade" einer Reihe von Sqlite-Datenbanken (die als Testfälle aufbewahrt wurden) auf ein sich ständig änderndes aktuelles Format beinhaltete. Das "Upgrade"-Framework würde eine Reihe von Skripten ausführen, die jeweils mindestens eine Transaktion durchführen, um eine Datenbank zu aktualisieren. Natürlich habe ich meine Datenbanken parallel aktualisiert (8 parallel, da ich mit einer mächtigen 8-Kern-CPU gesegnet war). Aber wie ich herausfand, gab es überhaupt keine Parallelisierungsbeschleunigung (eher einen leichten Hit ), da der Prozess vollständig IO-gebunden war. Komisch, das Upgrade-Framework in ein Skript zu packen, das jede Datenbank nach /dev/shm kopiert , es dort aktualisiert und zurück auf die Festplatte kopiert, war ungefähr 100-mal schneller (immer noch mit 8 parallel). Als Bonus war der PC brauchbar auch beim Aktualisieren von Datenbanken.

Wo tmpfs angemessen ist

Die angemessene Verwendung von tmpfs besteht darin, unnötiges Schreiben flüchtiger Daten zu vermeiden. Effektives Deaktivieren von Writeback , wie das Setzen von /proc/sys/vm/dirty_writeback_centisecs bis unendlich auf einem regulären Dateisystem.

Dies hat sehr wenig mit der Leistung zu tun, und ein Scheitern ist ein viel geringeres Problem als der Missbrauch von fsync:Das Writeback-Timeout bestimmt, wie träge der Festplatteninhalt nach dem Pagecache-Inhalt aktualisiert wird, und der Standardwert von 5 Sekunden ist eine lange Zeit für einen Computer – Eine Anwendung kann eine Datei im Pagecache beliebig oft überschreiben, aber der Inhalt auf der Festplatte wird nur etwa alle 5 Sekunden aktualisiert. Es sei denn, die Anwendung erzwingt es mit fsync. Denken Sie darüber nach, wie oft eine Anwendung in dieser Zeit eine kleine Datei ausgeben kann, und Sie sehen, warum es ein viel größeres Problem wäre, jede einzelne Datei zu synchronisieren.

Wobei Ihnen tmpfs nicht helfen kann

• Leistung lesen. Wenn Ihre Daten heiß sind (was besser ist, wenn Sie in Betracht ziehen, sie in tmpfs zu behalten), werden Sie sowieso den Pagecache treffen. Der Unterschied besteht darin, dass der Pagecache nicht getroffen wird. Wenn dies der Fall ist, gehen Sie weiter unten zu "Wo tmpfs sux".
• Kurzlebige Dateien. Diese können ihr ganzes Leben im Pagecache verbringen (als dirty Seiten), bevor sie überhaupt ausgeschrieben werden. Es sei denn, Sie erzwingen es mit fsync natürlich.

Wo tmpfs sux

kalt halten Daten. Sie könnten versucht sein zu glauben, dass das Bereitstellen von Dateien aus dem Auslagerungsbereich genauso effizient ist wie ein normales Dateisystem, aber es gibt ein paar Gründe, warum dies nicht der Fall ist:

• Der einfachste Grund:Es gibt nichts, was moderne Speichergeräte (sei es festplatten- oder flashbasiert) mehr lieben, als ziemlich sequentielle Dateien zu lesen, die ordentlich durch ein richtiges Dateisystem organisiert sind. Das Austauschen von 4-KiB-Blöcken wird dies wahrscheinlich nicht verbessern.
• Die versteckten Kosten:austauschen . Tmpfs-Seiten sind schmutzig — Sie müssen irgendwo geschrieben werden (um sie auszutauschen), um aus dem Pagecache entfernt zu werden, im Gegensatz zu einer sauberen Datei Seiten, die sofort gelöscht werden können. Dies ist eine zusätzliche Schreibstrafe für alles andere, das um Speicher konkurriert – betrifft etwas anderes zu einem anderen Zeitpunkt als die Verwendung dieser tmpfs-Seiten.

Okay, hier ist die Realität.

Sowohl tmpfs als auch ein normales Dateisystem sind ein Speichercache über der Festplatte.

Das tmpfs verwendet Arbeitsspeicher und Auslagerungsspeicher, da sein Sicherungsspeicher ein Dateisystem einen bestimmten Bereich der Festplatte verwendet, und es ist auch nicht in der Größe des Dateisystems begrenzt. Es ist durchaus möglich, ein 200-GB-tmpfs auf einem Computer mit weniger als einem GB RAM zu haben, wenn Sie haben genug Swapspace.

Der Unterschied besteht darin, wann Daten auf die Festplatte geschrieben werden. Bei einem tmpfs werden die Daten NUR geschrieben, wenn der Speicher zu voll wird oder die Daten wahrscheinlich nicht bald verwendet werden. Die meisten normalen Linux-Dateisysteme von OTOH sind so konzipiert, dass sie immer einen mehr oder weniger konsistenten Datensatz auf der Festplatte haben, sodass sie nicht alles verlieren, wenn der Benutzer den Stecker zieht.

Ich persönlich bin es gewohnt, Betriebssysteme zu haben, die nicht abstürzen, und USV-Systeme (z. B. Laptop-Akkus), daher denke ich, dass die ext2/3-Dateisysteme mit ihrem 5-10-Sekunden-Checkpoint-Intervall zu paranoid sind. Das ext4-Dateisystem ist mit einem 10-Minuten-Checkpoint besser, außer dass es Benutzerdaten als zweitklassig behandelt und sie nicht schützt. (ext3 ist dasselbe, aber Sie bemerken es wegen des 5-Sekunden-Checkpoints nicht)

Dieses häufige Checkpointing bedeutet, dass ständig unnötige Daten auf die Festplatte geschrieben werden, sogar für /tmp.

Das Ergebnis ist also, dass Sie Auslagerungsspeicher so groß erstellen müssen, wie Sie Ihr /tmp benötigen (auch wenn Sie eine Auslagerungsdatei erstellen müssen) und diesen Platz verwenden müssen, um ein tmpfs der erforderlichen Größe in /tmp einzuhängen.

Verwenden Sie NIEMALS /dev/shm.

Es sei denn, Sie verwenden es für sehr kleine (wahrscheinlich mit Mmap versehene) IPC-Dateien und Sie sind sicher, dass es existiert (es ist kein Standard) und die Maschine hat mehr als genug Speicher + Swap zur Verfügung.