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

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

Da Wikipedia:

Le recenti build del kernel Linux 2.6 hanno iniziato a offrire /dev/shm come memoria condivisa sotto forma di ramdisk, più specificamente come una directory scrivibile da tutti che è archiviata in memoria con un limite definito in /etc/default/tmpfs. Il supporto /dev/shm è completamente facoltativo all'interno del file di configurazione del kernel. È incluso per impostazione predefinita in entrambe le distribuzioni Fedora e Ubuntu, dove è ampiamente utilizzato dall'applicazione Pulseaudio.

/tmp è la posizione dei 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, puoi utilizzare /dev/shm invece di /tmp per l'aumento delle prestazioni, se il tuo processo è ad alta intensità di I/O e utilizza ampiamente file temporanei.

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

Ricorda quel /tmp può far parte dell'/ filesystem invece di un montaggio separato, e quindi può crescere come richiesto. La dimensione di /dev/shm è limitato dalla RAM in eccesso sul sistema e quindi è più probabile che tu rimanga senza spazio su questo filesystem.

In ordine decrescente di tmpfs probabilità:

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

Dal momento che stai chiedendo un tmpfs specifico per Linux punto di montaggio rispetto a una directory definita in modo portabile che può be tmpfs (a seconda del tuo amministratore di sistema e dell'impostazione predefinita per la tua distribuzione), la tua domanda ha due aspetti, che altre risposte hanno enfatizzato in modo diverso:

1. Uso appropriato di varie directory tmp
2. Uso appropriato di tmpfs

Uso appropriato di varie directory tmp

Basato sull'antico Filesystem Hierarchy Standard e su ciò che Systemd dice in merito.

• In caso di dubbio, usa /tmp .
• Usa /var/tmp per i dati che dovrebbero persistere tra i riavvii.
• Usa /var/tmp per dati di grandi dimensioni che potrebbero non entrare facilmente nella RAM (supponendo che /var/tmp ha più spazio disponibile – solitamente un presupposto ragionevole).
• Usa /dev/shm solo come effetto collaterale della chiamata a shm_open() . Il pubblico previsto è costituito da buffer delimitati che vengono sovrascritti all'infinito. Quindi questo è per file di lunga durata il cui contenuto è volatile e non eccessivamente grande.
• Sicuramente non usare /dev/shm per gli eseguibili (di qualsiasi tipo), poiché è comunemente montato noexec .
• Se hai ancora dei dubbi, fornisci all'utente un modo per eseguire l'override. Per la minima quantità di sorpresa, fai come mktemp e onorare il TMPDIR variabile d'ambiente.

Dove eccelle tmpfs

È importante dire che dove tmpfs eccelle davvero, sopra ogni altra cosa, è nascondere un bug di prestazioni che è dolorosamente significativo su un disco rotante. Quindi, se risolverlo è un'opzione, questo è ovviamente l'uso inappropriato di tmpfs :

fsync è un no-op su tmpfs. Questa chiamata di sistema dice al sistema operativo di svuotare la cache della pagina associata a un file, fino a svuotare la cache di scrittura del relativo dispositivo di archiviazione, il tutto impedendo al programma che l'ha emesso di fare qualsiasi progresso:una barriera di scrittura molto rozza . È uno strumento necessario nella confezione solo perché i protocolli di archiviazione non sono realizzati pensando alle transazioni. E la memorizzazione nella cache è presente in primo luogo per consentire ai programmi di eseguire milioni di piccole scritture su un file senza notare quanto sia effettivamente lento scrivere su un dispositivo di archiviazione:tutte le scritture effettive avvengono in modo asincrono o fino a fsync viene richiamato, che è l'unico punto in cui le prestazioni di scrittura vengono percepite direttamente dal programma.

Quindi, se ti ritrovi a utilizzare tmpfs (o eatmydata) solo per sconfiggere fsync, allora tu (o qualche altro sviluppatore nella catena) stai facendo qualcosa di sbagliato. Significa che le transazioni verso il dispositivo di archiviazione sono inutilmente dettagliate per il tuo scopo:sei chiaramente disposto a saltare alcuni punti di salvataggio per le prestazioni, poiché ora sei arrivato all'estremo di sabotarli tutti:raramente è il miglior compromesso. Inoltre, è qui nella terra delle prestazioni delle transazioni che si trovano alcuni dei maggiori vantaggi di avere un SSD:qualsiasi SSD degno di questo nome funzionerà fuori dal mondo rispetto a quello che può sopportare un disco rotante (7200 rpm =120 Hz, se nessun altro vi accede). Anche le schede di memoria flash variano ampiamente su questa metrica (è un compromesso con le prestazioni sequenziali e la valutazione della classe della scheda SD considera solo quest'ultima). Quindi attenzione, sviluppatori con SSD incredibilmente veloci, a non forzare i vostri utenti in questo caso d'uso!

Vuoi sentire una storia ridicola? Il mio primo fsync lezione:ho svolto un lavoro che prevedeva l'"aggiornamento" di routine di un gruppo di database Sqlite (conservati come casi di test) a un formato corrente in continua evoluzione. Il framework di "aggiornamento" eseguirà una serie di script, effettuando almeno una transazione ciascuno, per aggiornare un database. Naturalmente, ho aggiornato i miei database in parallelo (8 in parallelo, poiché sono stato benedetto con una potente CPU a 8 core). Ma come ho scoperto, non c'era alcun tipo di accelerazione della parallelizzazione (piuttosto un leggero hit ) perché il processo era interamente associato all'IO. Esilarante, avvolgere il framework di aggiornamento in uno script che copiava ogni database in /dev/shm , l'ho aggiornato lì e copiato di nuovo su disco era circa 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 consiste nell'evitare la scrittura non necessaria di dati volatili. Disabilitazione efficace del writeback , come impostare /proc/sys/vm/dirty_writeback_centisecs all'infinito su un normale filesystem.

Questo ha ben poco a che fare con le prestazioni, e il fallimento di questo è un problema molto minore rispetto all'abuso di fsync:il timeout di writeback determina la lentezza con cui il contenuto del disco viene aggiornato dopo il contenuto della cache della pagina e l'impostazione predefinita di 5 secondi è un tempo lungo per un computer – un'applicazione può sovrascrivere un file tutte le volte che vuole, in pagecache, ma il contenuto su disco viene aggiornato solo una volta ogni 5 secondi circa. A meno che l'applicazione non lo imponga con fsync, cioè. Pensa a quante volte un'applicazione può generare un file di piccole dimensioni in questo lasso di tempo e capirai perché sincronizzare ogni singolo file sarebbe un problema molto più grande.

In cosa tmpfs non può aiutarti

• Leggi le prestazioni. Se i tuoi dati sono caldi (il che è meglio se consideri di tenerli in tmpfs), raggiungerai comunque la pagecache. La differenza è quando non si accede alla cache di pagina; se questo è il caso, vai a "Dove tmpfs sux", di seguito.
• File di breve durata. Questi possono vivere tutta la loro vita nella pagecache (come file dirty pagine) prima di essere mai scritto. A meno che non lo forzi con fsync ovviamente.

Dove tmpfs sux

Mantenere il freddo dati. Potresti essere tentato di pensare che servire i file fuori dallo swap sia altrettanto efficiente di un normale filesystem, ma ci sono un paio di motivi per cui non lo è:

• La ragione più semplice:non c'è niente che i dispositivi di archiviazione contemporanei (sia harddisk che basati su flash) amino di più della lettura di file abbastanza sequenziali ordinatamente organizzati da un filesystem adeguato. È improbabile che lo scambio di blocchi da 4 KiB migliori su questo.
• Il costo nascosto:scambiare out . Le pagine tmpfs sono sporche — devono essere scritti da qualche parte (da scambiare) per essere sfrattati dalla pagecache, al contrario di puliti supportati da file pagine che possono essere rilasciate all'istante. Questa è una penalità di scrittura aggiuntiva 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 la memoria e lo spazio di scambio in quanto è un archivio di backup che un filesystem utilizza un'area specifica del disco, nessuno dei due è limitato nella dimensione che può essere il filesystem, è del tutto possibile avere un tmpfs da 200 GB su una macchina con meno di un GB di RAM se hai abbastanza spazio di scambio.

La differenza sta nel momento in cui i dati vengono scritti sul disco. Per un tmpfs i dati vengono scritti SOLO quando la memoria diventa troppo piena o è improbabile che i dati vengano utilizzati presto. OTOH la maggior parte dei normali filesystem Linux sono progettati per avere sempre un insieme 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 vanno in crash 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 te ne accorgi 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 scambio grande quanto ti serve che sia /tmp (anche se devi creare un file di scambio) e usare quello spazio per montare un tmpfs della dimensione richiesta su /tmp.

NON usare MAI /dev/shm.

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