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

Wann soll ich verwenden /dev/shm/und wann soll ich verwenden /tmp/? Kann ich mich immer darauf verlassen, dass beide bei Unices dabei sind?

/dev/shmist ein temporäres Dateispeicher-Dateisystem, dh tmpfs , das RAM für den Sicherungsspeicher verwendet. Es kann als gemeinsam genutzte Speicherimplementierung fungieren, die IPC erleichtert .

Aus Wikipedia :

Neuere 2.6 Linux-Kernel-Builds bieten / dev / shm nun als gemeinsam genutzten Speicher in Form einer Ramdisk an, genauer gesagt als weltweit beschreibbares Verzeichnis, das mit einem definierten Limit in / etc / default / tmpfs im Speicher abgelegt ist.  Die Unterstützung von / dev / shm ist in der Kernel-Konfigurationsdatei völlig optional.   Es ist standardmäßig in Fedora- und Ubuntu-Distributionen enthalten und wird dort am häufigsten von der Pulseaudio-Anwendung verwendet.             ^{(Betonung hinzugefügt.)}

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

Da RAM wesentlich schneller als Plattenspeicher ist, können Sie verwenden , /dev/shmanstatt /tmpfür die Leistungssteigerung , wenn Ihr Prozess I / O - intensiv ist und verwendet ausgiebig temporäre Dateien.

Um Ihre Fragen zu beantworten: Nein, Sie können sich nicht immer darauf verlassen, /dev/shmdass Sie anwesend sind, schon gar nicht auf Computern, auf denen der Speicher voll ist. Sie sollten verwenden, es /tmpsei denn, Sie haben einen sehr guten Grund für die Verwendung /dev/shm.

Denken Sie daran, dass /tmpdies Teil des /Dateisystems sein kann, anstatt eines separaten Mounts, und daher nach Bedarf erweitert werden kann. Die Größe von /dev/shmist durch den überschüssigen RAM-Speicher des Systems begrenzt. Daher ist es wahrscheinlicher, dass Ihnen auf diesem Dateisystem der Speicherplatz ausgeht.

In absteigender Reihenfolge der tmpfsWahrscheinlichkeit:

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

Da Sie über ein Linux - spezifische fragen tmpfs Einhängepunkt im Vergleich zu einem portably definiert Verzeichnisses , das kann tmpfs sein (abhängig von Ihrem Sysadmin und was ist Standard für Ihre Distribution), Ihre Frage hat zwei Aspekte, die anderen Antworten unterschiedlich betont haben:

1. Wann diese Verzeichnisse zu verwenden sind, wird empfohlen
2. Wann ist es angebracht, tmpfs zu verwenden

Gute Praktiken

Konservative Ausgabe (Mischung aus Konventionen von FHS und allgemeiner Verwendung):

• Im Zweifelsfall verwenden /tmp.
• Verwenden Sie diese Option /var/tmpfür große Datenmengen, die möglicherweise nicht leicht in den RAM passen.
• Verwenden Sie diese Option /var/tmpfür Daten, die für einen Neustart von Vorteil sind (z. B. einen Cache).
• Verwenden Sie /dev/shmals Nebeneffekt des Aufrufs shm_open(). Die Zielgruppe besteht aus begrenzten Puffern, die endlos überschrieben werden. Das ist also für langlebige Dateien, deren Inhalt flüchtig und nicht besonders groß ist.
• Wenn Sie immer noch Zweifel haben, geben Sie dem Benutzer die Möglichkeit, diese zu überschreiben. Beispielsweise berücksichtigt das mktempProgramm die TMPDIRUmgebungsvariable.

Pragmatische Ausgabe:

Verwenden /dev/shmSie diese Option, /var/tmpwenn die Verwendung von tmpfs wichtig ist, andernfalls /tmp.

Wo tmpfs sich auszeichnet

fsyncist ein No-Op auf tmpfs. Dieser Syscall ist der Feind Nummer eins für (IO-) Leistung (und Flash-Langlebigkeit, wenn Sie sich darum kümmern), obwohl Sie feststellen, dass Sie tmpfs (oder eatmydata) verwenden) nur um fsync zu besiegen, machen Sie (oder ein anderer Entwickler in der Kette) etwas falsch. Dies bedeutet, dass die Transaktionen in Richtung des Speichergeräts für Ihren Zweck unnötig feinkörnig sind - Sie sind eindeutig bereit, einige Sicherungspunkte für die Leistung zu überspringen, da Sie jetzt das Äußerste getan haben, um sie alle zu sabotieren - selten der beste Kompromiss. Hier in der Transaktions-Performance gibt es auch einige der größten Vorteile einer SSD: Jede anständige SSD wird eine unübertroffene Leistung erbringen, verglichen mit der Leistung einer sich drehenden Festplatte (7200 U / min = 120 Hz) , falls nichts anderes darauf zugreift), ganz zu schweigen von Flash-Speicherkarten, die in dieser Metrik stark variieren (nicht zuletzt, weil es sich um einen Kompromiss mit der sequentiellen Leistung handelt, nach der sie bewertet werden, z. B. SD-Kartenklassenbewertung). Hüte dich,

Willst du eine lächerliche Geschichte hören? Meine erste fsyncLektion: Ich hatte eine Aufgabe, bei der regelmäßig eine Reihe von SQLite-Datenbanken (die als Testfälle aufbewahrt werden) auf ein sich ständig änderndes aktuelles Format "aktualisiert" wurden. Das "Upgrade" -Framework würde eine Reihe von Skripten ausführen, die jeweils mindestens eine Transaktion ausfü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 Beschleunigung der Parallelisierung (eher ein kleiner Treffer ), da der Prozess vollständig IO-gebunden war. Das Upgrade-Framework in ein Skript zu packen, in das jede Datenbank kopiert /dev/shm, dort aktualisiert und auf die Festplatte zurückkopiert wurde, war 100-mal schneller (immer noch mit 8 parallel). Als Bonus war der PC nutzbar auch beim Upgrade von Datenbanken.

Wo tmpfs angebracht ist

Mit tmpfs können Sie unnötiges Schreiben flüchtiger Daten vermeiden. Deaktivieren Sie effektiv das Zurückschreiben , wie z . B. das Einstellen /proc/sys/vm/dirty_writeback_centisecsauf unendlich in einem regulären Dateisystem.

Dies hat sehr wenig mit der Leistung zu tun, und ein Fehlschlagen ist ein viel geringeres Problem als der Missbrauch von fsync: Das Zeitlimit für das Zurückschreiben bestimmt, wie träge der Festplatteninhalt nach dem Inhalt des Pagecaches aktualisiert wird, und die Standardeinstellung von 5 Sekunden ist eine lange Zeit für einen Computer - Eine Anwendung kann eine Datei im PageCache beliebig oft überschreiben, der Inhalt auf der Festplatte wird jedoch nur etwa alle 5 Sekunden aktualisiert. Es sei denn, die Anwendung erzwingt dies mit fsync. Überlegen Sie, wie oft eine Anwendung in dieser Zeit eine kleine Datei ausgeben kann, und Sie sehen, warum das Synchronisieren jeder einzelnen Datei ein viel größeres Problem darstellt.

Was tmpfs kann dir nicht helfen

• Leseleistung. Wenn Ihre Daten heiß sind (was besser ist, wenn Sie daran denken, sie in tmpfs zu belassen), werden Sie trotzdem auf den Seitencache zugreifen. Der Unterschied besteht darin, dass der Pagecache nicht aufgerufen wird. Wenn dies der Fall ist, fahren Sie unten mit "Where tmpfs sux" fort.
• Kurzlebige Dateien. Diese können ihr ganzes Leben im Pagecache verbringen (als schmutzige Seiten), bevor sie jemals ausgeschrieben werden. Es sei denn, Sie zwingen es fsyncnatürlich mit.

Wo tmpfs sux

Bewahren Sie kalte Daten auf. Sie könnten der Meinung sein, dass das Bereitstellen von Dateien aus dem Swap genauso effizient ist wie ein normales Dateisystem, aber es gibt mehrere Gründe, warum dies nicht der Fall ist:

• Der einfachste Grund: Es gibt nichts, was moderne Speichergeräte (sei es auf Festplatte oder Flash-Basis) mehr lieben als das Lesen von ziemlich sequentiellen Dateien, die ordentlich von einem richtigen Dateisystem organisiert sind. Das Austauschen von 4-KB-Blöcken wird sich wahrscheinlich nicht verbessern.
• Die versteckt Kosten: Swapping aus . Tmpfs Seiten sind schmutzig - sie müssen irgendwo geschrieben werden (Swap) von Pagecache vertrieben werden, im Gegensatz zu gesicherten Datei saubere Seiten , die sofort gelöscht werden kann. Dies ist eine zusätzliche Schreibstrafe für alles andere, was um Speicher konkurriert - wirkt sich auf etwas anderes zu einem anderen Zeitpunkt aus als auf die Verwendung dieser tmpfs-Seiten.

Okay, hier ist die Realität.

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

Der tmpfs verwendet Speicher und Swapspace als Backup-Speicher. Ein Dateisystem verwendet einen bestimmten Bereich der Festplatte. Weder ist die Größe des Dateisystems begrenzt, noch können 200 GB tmpfs auf einem Computer mit weniger als GB RAM vorhanden sein, wenn Sie haben genug Swapspace.

Der Unterschied besteht darin, wann Daten auf die Festplatte geschrieben werden. Für einen 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 mehr oder weniger konsistente Daten auf der Festplatte haben. Wenn der Benutzer also den Stecker zieht, verliert er nicht alles.

Persönlich bin ich es gewohnt, Betriebssysteme zu haben, die nicht abstürzen, und USV-Systeme (z. B. Laptop-Batterien), sodass ich denke, dass die ext2 / 3-Dateisysteme mit ihrem Checkpoint-Intervall von 5 bis 10 Sekunden zu paranoid sind. Das ext4-Dateisystem ist mit einem 10-minütigen Checkpoint besser, außer dass es Benutzerdaten als zweite Klasse behandelt und sie nicht schützt. (ext3 ist das selbe, aber man merkt es nicht wegen dem 5 Sekunden Checkpoint)

Diese häufigen Checkpoints bedeuten, dass ständig unnötige Daten auf die Festplatte geschrieben werden, auch für / tmp.

Das Ergebnis ist also, dass Sie einen Swap-Speicherplatz erstellen müssen, der so groß ist, wie Sie es für Ihr / tmp benötigen (auch wenn Sie eine Swap-Datei erstellen müssen), und diesen Speicherplatz verwenden, um ein tmpfs der erforderlichen Größe auf / tmp zu mounten.

NIEMALS / dev / shm benutzen.

Es sei denn, Sie verwenden es für sehr kleine (wahrscheinlich MMAP-fähige) IPC-Dateien, und Sie sind sicher, dass es vorhanden ist (es ist kein Standard) und der Computer über mehr als genug Arbeitsspeicher + Swap verfügt.

Verwenden Sie / tmp / für temporäre Dateien. Verwenden Sie / dev / shm /, wenn Sie den gemeinsamen Speicher verwenden möchten (dh die Kommunikation zwischen den Prozessen über Dateien).

Sie können sich darauf verlassen, dass / tmp / da ist, aber / dev / shm / ist ein relativ neues Linux-Ding.

Ein anderes Mal, wenn Sie / dev / shm (für Linux 2.6 und höher) verwenden sollten, benötigen Sie ein garantiertes tmpfs-Dateisystem, da Sie nicht wissen, ob Sie auf die Festplatte schreiben können .

Ein Überwachungssystem, mit dem ich vertraut bin, muss temporäre Dateien ausgeben, während der Bericht zur Übermittlung an einen zentralen Server erstellt wird. In der Praxis ist es weitaus wahrscheinlicher, dass Schreibvorgänge in ein Dateisystem verhindert werden (entweder zu wenig Speicherplatz oder ein zugrunde liegender RAID-Fehler hat das System in einen schreibgeschützten Hardwaremodus versetzt), aber Sie können trotzdem hinhinken, um einen Alarm auszulösen Wenn etwas den gesamten verfügbaren Speicher so verändert, dass tmpfs unbrauchbar wird (und die Box nicht tot ist). In solchen Fällen wird ein Überwachungssystem es vorziehen, in den RAM zu schreiben, um möglicherweise eine Warnung über eine volle Festplatte oder eine defekte / ausfallende Hardware zu senden.

/ dev / shm wird für bestimmte Gerätetreiber und Programme des gemeinsam genutzten virtuellen Speichersystems verwendet.

Wenn Sie ein Programm erstellen, für das ein virtueller Speicherheap erforderlich ist, der dem virtuellen Speicher zugeordnet werden soll. Dies geht doppelt so, wenn Sie mehrere Prozesse oder Threads benötigen, um sicher auf diesen Speicher zugreifen zu können.

Tatsache ist, dass nur, weil der Treiber eine spezielle Version von tmpfs verwendet, dies nicht bedeutet, dass Sie sie als generische tmpfs-Partition verwenden sollten. Stattdessen sollten Sie einfach eine andere tmpfs-Partition erstellen, wenn Sie eine für Ihr temporäres Verzeichnis möchten.

Bei PERL mit mindestens 8 GB auf jedem Computer (auf dem Linux Mint ausgeführt wird) ist es meiner Meinung nach eine gute Angewohnheit, DB_File-basierte (Datenstruktur in einer Datei) komplexe Algorithmen mit Millionen von Lese- und Schreibvorgängen mithilfe von / dev / auszuführen. shm

In anderen Sprachen, die nicht überall zu finden sind, kopiere ich die Datei, um das Starten und Stoppen der Netzwerkübertragung (lokale Bearbeitung einer Datei, die sich auf einem Server in einer Client-Server-Atmosphäre befindet) mithilfe einer Batch-Datei zu vermeiden ganze (300-900MB) Datei auf einmal nach / dev / shm, starte das Programm mit der Ausgabe nach / dev / shm, schreibe die Ergebnisse zurück auf den Server und lösche sie aus / dev / shm

Wenn ich weniger RAM hätte, würde ich das natürlich nicht tun. Normalerweise liest das speicherinterne Dateisystem von / dev / shm als Größe die Hälfte des verfügbaren RAM. Die normale Verwendung von RAM ist jedoch konstant. Auf einem Gerät mit 2 GB oder weniger ist dies also nicht möglich. Um die Umschreibung in eine Übertreibung umzuwandeln, gibt es oft Dinge im RAM, die selbst das System nicht gut meldet.