Quando dovrei usare / dev / shm / e quando dovrei usare / tmp /?

Quando dovrei usare /dev/shm/e quando dovrei usare /tmp/? Posso sempre fare affidamento sul fatto che entrambi siano presenti su Unices?

/dev/shmè un file system di archiviazione di file temporaneo, ad esempio tmpfs , che utilizza la RAM per l'archivio di backup. Può funzionare come un'implementazione della memoria condivisa che facilita l' IPC .

Da Wikipedia :

I recenti build del kernel Linux 2.6 hanno iniziato a offrire / dev / shm come memoria condivisa sotto forma di ramdisk, più specificamente come directory scrivibile dal mondo che è archiviata in memoria con un limite definito in / etc / default / tmpfs.  Il supporto / dev / shm è completamente opzionale nel file di configurazione del kernel.   È incluso di default nelle distribuzioni Fedora e Ubuntu, dove è ampiamente utilizzato dall'applicazione Pulseaudio.             ^{(Enfasi aggiunta.)}

/tmpè il percorso per i file temporanei come definito nel Filesystem Hierarchy Standard , seguito da quasi tutte le distribuzioni Unix e Linux.

Poiché la RAM è significativamente più veloce dell'archiviazione su disco, è possibile utilizzare /dev/shmanziché /tmpper aumentare le prestazioni , se il processo è intensivo di I / O e utilizza ampiamente file temporanei.

Per rispondere alle tue domande: No, non puoi sempre fare affidamento sul fatto di /dev/shmessere presente, certamente non su macchine a corto di memoria. Dovresti usare a /tmpmeno che tu non abbia un'ottima ragione per usarlo /dev/shm.

Ricorda che /tmppuò far parte del /filesystem invece di un mount separato, e quindi può crescere come richiesto. La dimensione di /dev/shmè limitata dall'eccesso di RAM sul sistema, e quindi è più probabile che rimanga a corto di spazio su questo filesystem.

In ordine decrescente di tmpfsprobabilità:

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

Dato che stai chiedendo un mountpoint tmpfs specifico per Linux rispetto a una directory definita in modo portabile che potrebbe essere tmpfs (a seconda del tuo sysadmin e di ciò che è predefinito per la tua distribuzione), la tua domanda ha due aspetti, che altre risposte hanno sottolineato in modo diverso:

1. Quando utilizzare queste directory, in base alle buone pratiche
2. Quando è appropriato usare tmpfs

Buone abitudini

Edizione conservativa (miscela di convenzioni da FHS e uso comune):

• In caso di dubbio, utilizzare /tmp.
• Utilizzare /var/tmpper dati di grandi dimensioni che potrebbero non rientrare facilmente nella RAM.
• Utilizzare /var/tmpper i dati utili per il riavvio (come una cache).
• Utilizzare /dev/shmcome effetto collaterale della chiamata shm_open(). Il pubblico previsto è buffer limitato che viene sovrascritto all'infinito. Quindi questo è per file di lunga durata il cui contenuto è volatile e non eccessivamente grande.
• In caso di dubbi, fornire all'utente la possibilità di eseguire l'override. Ad esempio, il mktempprogramma onora la TMPDIRvariabile d'ambiente.

Edizione pragmatica:

Utilizzare /dev/shmquando è importante usare tmpfs, /var/tmpquando è importante non farlo, altrimenti /tmp.

Dove tmpfs eccelle

fsyncè una no-op su tmpfs. Questo syscall è il nemico numero uno delle prestazioni (IO) (e della longevità flash, se ti interessa), anche se ti ritrovi a usare tmpfs (o eatmydata) solo per sconfiggere fsync, allora tu (o qualche altro sviluppatore della catena) stai facendo qualcosa di sbagliato. Significa che le transazioni verso il dispositivo di archiviazione sono inutilmente granulose per il tuo scopo - sei chiaramente disposto a saltare alcuni punti di salvataggio per le prestazioni, poiché ora sei arrivato all'estremo di sabotare tutti - raramente il miglior compromesso. Inoltre, è qui nella terra delle prestazioni delle transazioni in cui si trovano alcuni dei maggiori vantaggi di avere un SSD: qualsiasi SSD decente eseguirà prestazioni fuori dal mondo rispetto a ciò che un disco rotante può eventualmente portare (7200 rpm = 120 Hz , se si sta accedendo a qualcun altro), per non parlare delle schede di memoria flash, che variano ampiamente su questa metrica (anche perché si tratta di un compromesso con prestazioni sequenziali, che è quello da cui sono classificate, ad esempio la classificazione della classe della scheda SD). Quindi attenzione

Vuoi ascoltare una storia ridicola? La mia prima fsynclezione: ho svolto un lavoro che prevedeva "l'aggiornamento" sistematico di un sacco di database Sqlite (mantenuti come test) in un formato attuale in continua evoluzione. Il framework "upgrade" eseguirà un gruppo di script, effettuando almeno una transazione ciascuno, per aggiornare un database. Naturalmente, ho aggiornato i miei database in parallelo (8 in parallelo, dato che sono stato benedetto con una potente CPU a 8 core). Ma come ho scoperto, non vi è stata alcuna accelerazione della parallelizzazione (piuttosto un leggero successo ) perché il processo era interamente legato all'IO. In modo esilarante, il wrapping del framework di aggiornamento in uno script in cui è stato copiato ogni database /dev/shm, aggiornato in quel punto e copiato su disco è stato 100 volte più veloce (sempre con 8 in parallelo). Come bonus, il PC era utilizzabile anche, durante l'aggiornamento dei database.

Dove tmpfs è appropriato

L'uso appropriato di tmpfs è di evitare la scrittura non necessaria di dati volatili. Disabilitare efficacemente il writeback , come impostare /proc/sys/vm/dirty_writeback_centisecssu infinito su un normale filesystem.

Ciò ha ben poco a che fare con le prestazioni, e fallire è una preoccupazione molto più piccola rispetto all'abuso di fsync: il timeout di writeback determina quanto pigramente il contenuto del disco viene aggiornato dopo il contenuto di pagecache e il valore predefinito di 5 secondi è molto tempo per un computer - un'applicazione può sovrascrivere un file con la frequenza che desidera, in pagecache, ma il contenuto su disco viene aggiornato solo una volta ogni 5 secondi. A meno che l'applicazione non lo costringa a farlo con fsync, cioè. Pensa a quante volte un'applicazione può produrre un piccolo file in questo momento e capisci perché fsyncing ogni singolo sarebbe un problema molto più grande.

Cosa tmpfs non può aiutarti

• Leggi le prestazioni. Se i tuoi dati sono caldi (il che è meglio se consideri di tenerli in tmpfs), colpirai comunque la pagecache. La differenza è quando non si colpisce il pagecache; in tal caso, vai su "Where tmpfs sux", di seguito.
• File di breve durata. Questi possono vivere le loro intere vite nel pagecache (come pagine sporche ) prima di essere mai scritti. A meno che non lo forzi, fsyncovviamente.

Dove tmpfs sux

Mantenere i dati freddi . Potresti essere tentato di pensare che la pubblicazione di file fuori dallo scambio sia efficace quanto un normale filesystem, ma ci sono un paio di ragioni per cui non lo è:

• Il motivo più semplice: non c'è nulla che i dispositivi di archiviazione contemporanei (siano essi hard disk o basati su flash) adorino di più che leggere file abbastanza sequenziali organizzati in modo ordinato da un vero filesystem. È improbabile che lo scambio in blocchi da 4KiB migliori.
• Il costo nascosto: Swapping fuori . Le pagine di Tmpfs sono sporche : devono essere scritte da qualche parte (per scambiare) per essere sfrattate da pagecache, al contrario delle pagine pulite con backup di file che possono essere eliminate istantaneamente. Questa è una penalità aggiuntiva in scrittura su tutto ciò che compete per la memoria - influisce su qualcos'altro in un momento diverso dall'uso di quelle pagine tmpfs.

Ok, ecco la realtà.

Sia tmpfs che un normale filesystem sono una cache di memoria su disco.

Il tmpfs utilizza memoria e spazio di swap in quanto il backing store di un filesystem utilizza un'area specifica del disco, né è limitato nella dimensione che può essere il filesystem, è abbastanza possibile avere un tmpfs da 200 GB su una macchina con meno di un GB di RAM se hai abbastanza spazio per lo scambio.

La differenza sta nella scrittura dei dati sul disco. Per un tmpfs i dati vengono scritti SOLO quando la memoria è troppo piena o è improbabile che i dati vengano usati presto. I filesystem Linux più normali di OTOH sono progettati per avere sempre un set di dati più o meno coerente sul disco, quindi se l'utente stacca la spina non perde tutto.

Personalmente, sono abituato ad avere sistemi operativi che non si arrestano in modo anomalo e sistemi UPS (ad esempio: batterie per laptop), quindi penso che i filesystem ext2 / 3 siano troppo paranoici con il loro intervallo di checkpoint di 5-10 secondi. Il filesystem ext4 è migliore con un checkpoint di 10 minuti, tranne per il fatto che tratta i dati dell'utente come di seconda classe e non li protegge. (ext3 è lo stesso ma non lo noti a causa del checkpoint di 5 secondi)

Questo frequente checkpoint significa che i dati non necessari vengono continuamente scritti su disco, anche per / tmp.

Quindi il risultato è che devi creare uno spazio di swap grande quanto hai bisogno del tuo / tmp (anche se devi creare un file di swap) e usare quello spazio per montare un tmpfs della dimensione richiesta su / tmp.

MAI utilizzare / dev / shm.

A meno che non lo si stia utilizzando per file IPC molto piccoli (probabilmente mmap'd) e si è sicuri che esista (non è uno standard) e che la macchina abbia più memoria sufficiente + swap disponibile.

Utilizzare / tmp / per i file temporanei. Utilizzare / dev / shm / quando si desidera la memoria condivisa (ad es. Comunicazione tra processi attraverso i file).

Puoi contare su / tmp / essere lì, ma / dev / shm / è una cosa Linux relativamente recente.

Un'altra volta in cui dovresti usare / dev / shm (per Linux 2.6 e versioni successive) è quando hai bisogno di un file system tmpfs garantito perché non sai se puoi scrivere su disco.

Un sistema di monitoraggio che conosco deve scrivere file temporanei durante la creazione di un rapporto per l'invio a un server centrale. In pratica, è molto più probabile che qualcosa impedisca la scrittura su un file system (spazio su disco insufficiente o un errore RAID sottostante ha spinto il sistema in una modalità di sola lettura hardware) ma sarai comunque in grado di zoppicare per avvisare a questo proposito che se qualcosa spirasse tutta la memoria disponibile in modo tale che tmpfs sarà inutilizzabile (e la scatola non sarà morta). In casi come questo, un sistema di monitoraggio preferirà scrivere su RAM in modo da essere potenzialmente in grado di inviare un avviso su un disco intero o hardware morto / morente.

/ dev / shm è usato per programmi e driver di dispositivo specifici del sistema di memoria virtuale condivisa.

Se si sta creando un programma che richiede un heap di memoria virtuale che deve essere mappato sulla memoria virtuale. Questo diventa doppio, quindi se hai bisogno di più processi o thread per poter accedere in modo sicuro a quella memoria.

Il fatto è che solo perché il driver utilizza una versione speciale di tmpfs per questo, non significa che dovresti usarlo come una partizione tmpfs generica. Invece, dovresti semplicemente creare un'altra partizione tmpfs se ne vuoi una per la tua directory temporanea.

In PERL, con un minimo di 8 GB su qualsiasi macchina (tutte con Linux Mint), sono di quella che penso sia una buona abitudine di fare algoritmi complessi basati su DB_File (struttura dei dati in un file) con milioni di letture e scritture usando / dev / shm

In altre lingue, non avendo gigether ovunque, per evitare gli inizi e gli arresti nel trasferimento di rete (lavorando localmente su un file che si trova su un server in un'atmosfera client-server), usando un file batch di qualche tipo, copierò il intero file (300-900 MB) contemporaneamente su / dev / shm, esegui il programma con output su / dev / shm, riscrivi i risultati sul server ed elimina da / dev / shm

Naturalmente, se avessi meno RAM, non lo farei. Normalmente, il file system in memoria di / dev / shm indica una dimensione pari alla metà della RAM disponibile. Tuttavia, l'uso ordinario di RAM è costante. Quindi non puoi davvero farlo su un dispositivo con 2 GB o meno. Per trasformare la parafrasi in iperbole, ci sono spesso cose nella RAM che persino il sistema non riporta bene.