Der Betrieb in / dev / shm verursacht einen Überlauf

Ich wiederhole Zehntausende ähnlicher Vorgänge in / dev / shm, wobei jeder ein Verzeichnis erstellt, Dateien geschrieben und dann entfernt hat. Früher ging ich davon aus, dass ich tatsächlich Verzeichnisse erstellt und entfernt habe, sodass der Speicherverbrauch recht niedrig sein musste. Es stellte sich jedoch heraus, dass die Nutzung ziemlich hoch war und schließlich einen Speicherüberlauf verursachte. Meine Fragen sind also: mit Operationen wie

mkdir /dev/shm/foo
touch /dev/shm/foo/bar
[edit] /dev/shm/foo/bar
....
rm -rf /dev/shm/foo

Wird es endlich zu einem Speicherüberlauf kommen? und wenn ja, warum ist das so, da es sie an Ort und Stelle zu entfernen scheint.

Hinweis: Dies ist eine zehntausende ähnliche Operation.

Neugierig, wie df -h /dev/shmviel RAM Sie beim Ausführen dieser Anwendung anzeigen ?

tmpfs

Standardmäßig wird es normalerweise mit 50% des physischen Arbeitsspeichers des Systems eingerichtet. Dies ist hier auf kernel.org unter der Dateisystemdokumentation für tmpfs dokumentiert. Es wird auch in der mountManpage erwähnt.

Auszug aus der Mount Manpage

Die maximale Anzahl von Inodes für diese Instanz. Der Standardwert ist die Hälfte der Anzahl Ihrer physischen RAM-Seiten oder (auf einem Computer mit Highmem) die Anzahl der Lowmem-RAM-Seiten, je nachdem, welcher Wert niedriger ist.

Bestätigung

Auf meinem Laptop mit 8 GB RAM habe ich das folgende Setup für /dev/shm:

$ df -h /dev/shm
Filesystem            Size  Used Avail Use% Mounted on
tmpfs                 3.9G  4.4M  3.9G   1% /dev/shm

Was ist los?

Ich denke, was passiert, ist, dass Sie nicht nur 50% Ihres Arbeitsspeichers für den Start zugewiesen bekommen, sondern im Wesentlichen die gesamten 50% im Laufe der Zeit verbrauchen und Ihren /dev/shmSpeicherplatz zusammen mit den anderen 50% des Arbeitsspeichers in den Swap verschieben.

Beachten Sie, dass ein weiteres Merkmal von tmpfsvs. darin ramfsbesteht, dass es tmpfsbei Bedarf in den Swap verschoben werden kann:

Auszug aus geekstuff.com

                    Table: Comparison of ramfs and tmpfs

Experimentation                          Tmpfs                Ramfs
---------------                          -----                -----
Fill maximum space and continue writing  Will display error   Will continue writing
Fixed Size                               Yes                  No
Uses Swap                                Yes                  No
Volatile Storage                         Yes                  Yes

Letztendlich handelt es sich um ein im RAM implementiertes Dateisystem, daher würde ich erwarten, dass es sich ein wenig wie beide verhält. Damit meine ich, dass Sie beim Löschen von Dateien / Verzeichnissen einige der physischen Speicherseiten für die Inode-Tabelle und einige für den tatsächlich von diesen Dateien / Verzeichnissen belegten Speicherplatz verwenden.

Wenn Sie Speicherplatz auf einer Festplatte verwenden, geben Sie normalerweise nicht den physischen Speicherplatz frei, sondern nur die Einträge in der Inode-Tabelle. Dies bedeutet, dass der von einer bestimmten Datei belegte Speicherplatz jetzt verfügbar ist.

Aus Sicht des RAM sind die von den Dateien belegten Speicherplätze also nur schmutzige Seiten im Speicher. So wird es sie im Laufe der Zeit pflichtbewusst austauschen.

Es ist unklar, ob tmpfsetwas Besonderes unternommen wird, um den tatsächlichen Arbeitsspeicher des von ihm bereitgestellten Dateisystems zu bereinigen. In mehreren Foren wurde erwähnt, dass die Leute sahen, dass es mehr als 15 Minuten dauerte, bis ihr System Speicherplatz für Dateien "zurückgewonnen" hatte, die sie in der gelöscht hatten /dev/shm.

Vielleicht wird dieses Dokument mit dem tmpfsTitel: tmpfs: Ein virtuelles Speicher-Dateisystem mehr Aufschluss darüber geben, wie es auf der unteren Ebene implementiert ist und wie es in Bezug auf das VMM funktioniert. Das Papier wurde speziell für SunOS geschrieben, könnte aber einige Hinweise enthalten.

Experimentieren

Die folgenden erfundenen Tests scheinen darauf hinzudeuten, /dev/shmdass sie sich selbst bereinigen können.

Experiment Nr. 1

Erstellen Sie ein Verzeichnis mit einer einzelnen Datei und löschen Sie das Verzeichnis 1000 Mal.

$ df -k /dev/shm
Filesystem           1K-blocks      Used Available Use% Mounted on
tmpfs                  3993744      5500   3988244   1% /dev/shm

$ for i in `seq 1 1000`;do mkdir /dev/shm/sam; echo "$i" \
      > /dev/shm/sam/file$i; rm -fr /dev/shm/sam;done

$ df -k /dev/shm
Filesystem           1K-blocks      Used Available Use% Mounted on
tmpfs                  3993744      5528   3988216   1% /dev/shm

Experiment Nr. 2

Erstellen Sie ein Verzeichnis mit einer einzelnen 50-MB-Datei und löschen Sie das Verzeichnis 300 Mal.

$ start_time=`date +%s`
$ for i in `seq 1 300`;do mkdir /dev/shm/sam;                     \
   dd if=/dev/random of=/dev/shm/sam/file$i bs=52428800 count=1 > \
   /dev/shm/sam/file$i.log; rm -fr /dev/shm/sam;done              \
   && echo run time is $(expr `date +%s` - $start_time) s

...
8 bytes (8 B) copied, 0.247272 s, 0.0 kB/s
0+1 records in
0+1 records out
9 bytes (9 B) copied, 1.49836 s, 0.0 kB/s
run time is 213 s

Auch hier gab es keine merkliche Zunahme des von /dev/shm.

$ df -k /dev/shm
Filesystem           1K-blocks      Used Available Use% Mounted on
tmpfs                  3993744      5500   3988244   1% /dev/shm

Fazit

Ich habe keine erkennbaren Auswirkungen beim Hinzufügen von Dateien und Verzeichnissen mit meinem bemerkt /dev/shm. Das mehrfache Ausführen der oben genannten Schritte schien ebenfalls keine Auswirkungen zu haben. Daher sehe ich kein Problem bei der Verwendung /dev/shmin der von Ihnen beschriebenen Weise.