it-swarm-eu.dev

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

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

126
Deleted

/dev/shm è un filesystem di archiviazione temporanea, cioè tmpfs , che utilizza RAM per il backing store. Può funzionare come un'implementazione della memoria condivisa che facilita IPC .

Da Wikipedia :

Le recenti versioni del kernel Linux 2.6 hanno iniziato a offrire/dev/shm come memoria condivisa sotto forma di un ramdisk, più specificamente come una directory scrivibile in tutto il mondo che è archiviata in memoria con un limite definito in/etc/default/tmpfs./dev/shm support è completamente facoltativo all'interno del file di configurazione del kernel. E 'incluso di default in entrambe le distribuzioni di Fedora e Ubuntu, dove è ampiamente usato dall'applicazione Pulseaudio.(Enfasi aggiunta.)

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

Poiché RAM è significativamente più veloce dell'archiviazione su disco, puoi utilizzare /dev/shm anziché /tmp per l'aumento delle prestazioni , se il tuo processo è intensivo di I/O e utilizza estensivamente file temporanei.

Per rispondere alle tue domande: No, non puoi sempre contare sul fatto che /dev/shm sia presente, certamente non su macchine pronte per la memoria. Dovresti usare /tmp a meno che tu non abbia una buona ragione per usare /dev/shm.

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

90
nagul

In ordine decrescente di tmpfsprobabilita ':

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

Dato che stai chiedendo di un mountpoint tmpfs specifico per Linux rispetto a una directory definita dal punto di vista che may essere tmpfs (a seconda del tuo sysadmin e di quello predefinito per la tua distribuzione), la tua domanda ha due aspetti, quali altre risposte hanno sottolineato in modo diverso:

  1. Quando utilizzare queste directory, basate su buona pratica
  2. Quando è appropriato usare tmpfs

Buone abitudini

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

  • In caso di dubbio, utilizzare /tmp.
  • Utilizza /var/tmp per i dati di grandi dimensioni che potrebbero non adattarsi facilmente alla ram.
  • Utilizza /var/tmp per i dati utili per mantenere i riavvii (come una cache).
  • Utilizza /dev/shm come effetto collaterale della chiamata shm_open(). Il pubblico previsto è un buffer limitato che viene sovrascritto all'infinito. Quindi questo è per i file longevi il cui contenuto è volatile e non troppo grande.
  • In caso di dubbio, fornire un modo per l'utente di eseguire l'override. Ad esempio, il programma mktemponora la variabile di ambiente TMPDIRname__.

Edizione pragmatica:

Usa /dev/shm quando è importante usare tmpfs, /var/tmp quando è importante non farlo, altrimenti /tmp.

Dove eccelle i tmpfs

fsyncè un no-op su tmpfs. Questo syscall è il nemico numero uno delle prestazioni (IO) (e la longevità del flash, se ci tieni a questo), anche se ti trovi a usare tmpfs (o eatmydata ) solo per sconfiggere fsync, allora tu (o qualche altro sviluppatore nella catena) stanno facendo qualcosa di sbagliato. Significa che le transazioni verso il dispositivo di archiviazione sono inutilmente a grana fine per il tuo scopo: sei chiaramente disposto a saltare alcuni punti di salvataggio per le prestazioni, dato che ora sei arrivato all'estremo di sabotarli tutti - raramente il miglior compromesso. Inoltre, è qui nella terra delle prestazioni della transazione in cui si trovano alcuni dei maggiori vantaggi dell'utilizzo di un SSD: qualsiasi SSD decente eseguirà out-of-this-world rispetto a quello che un disco rotante può eventualmente utilizzare (7200 rpm = 120 Hz , se notifica altro sta accedendo a esso), per non parlare delle schede di memoria flash, che variano ampiamente su questa metrica (non ultimo perché si tratta di un compromesso con prestazioni sequenziali, che è ciò che sono valutate da, ad esempio, classificazione della scheda SD). Quindi, fai attenzione agli sviluppatori con SSD fiammanti e veloci, per non forzare gli utenti in questo caso d'uso!

Vuoi sentire una storia ridicola? La mia prima lezione fsyncname__: ho avuto un lavoro che prevedeva regolarmente l'aggiornamento di un gruppo di database Sqlite (mantenuti come test) in un formato corrente in continua evoluzione. Il framework di "upgrade" eseguiva una serie di script, effettuando almeno una transazione ciascuno, per aggiornare un database. Ovviamente, ho aggiornato i miei database in parallelo (8 in parallelo, dato che sono stato benedetto con una potente CPU 8 core). Ma come ho scoperto, non c'era alcuna accelerazione della parallelizzazione (piuttosto un leggero hit) perché il processo era interamente IO bound. Esilarante, il wrapping del framework di aggiornamento in uno script che copiava ciascun database su /dev/shm, lo aggiornava lì e lo copiava su disco era 100 volte più veloce (ancora con 8 in parallelo). Come bonus, anche il PC era utilizzabile durante l'aggiornamento dei database.

Dove tmpfs è appropriato

L'uso appropriato di tmpfs è quello di evitare la scrittura non necessaria di dati volatili. Disabilitazione effettiva di writeback, come l'impostazione /proc/sys/vm/dirty_writeback_centisecs all'infinito su un normale filesystem.

Questo ha poco a che fare con le prestazioni, e in caso contrario si tratta di una preoccupazione molto minore rispetto all'abuso di fsync: il timeout di writeback determina quanto pigramente il contenuto del disco viene aggiornato dopo il contenuto della pagecach e l'impostazione predefinita di 5 secondi è un tempo lungo per un computer - un'applicazione può sovrascrivere un file ogni volta che lo desidera, in pagecache, ma il contenuto sul disco viene aggiornato solo una volta ogni 5 secondi. A meno che l'applicazione non lo imponga con fsync, cioè. Pensa a quante volte un'applicazione può emettere un piccolo file in questo momento, e capisci perché fsyncing ogni singolo sarebbe un problema molto più grande.

Cosa tmpfs non ti può aiutare

  • Leggi le prestazioni. Se i tuoi dati sono caldi (cosa che sarebbe meglio se tenti di tenerlo in tmpfs), colpisci comunque il pagecach. La differenza è quando non colpisci il pagecache; se questo è il caso, vai a "Dove tmpfs sux", di seguito.
  • File di breve durata. Questi possono vivere la loro intera vita nella pagecache (come sporco pagine) prima di essere mai scritti. A meno che non lo forziate con fsyncovviamente.

Dove tmpfs sux

Mantenere freddo dati. Potresti essere tentato di pensare che la pubblicazione di file fuori dallo swap sia efficiente 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 memorizzazione contemporanei (sia esso harddisk o basato su flash) ami di più che leggere file abbastanza sequenziali organizzati in modo ordinato da un file system adeguato. Lo swapping nei blocchi 4KiB è improbabile che migliori su questo.
  • Il costo nascosto: scambio out. Le pagine Tmpfs sono dirty - devono essere scritte da qualche parte (da scambiare) per essere sfrattate dalle pagine pagecache, al contrario delle file clean che possono essere eliminate immediatamente. Questa è una penalità in più di scrittura su tutto ciò che compete per la memoria - influisce su qualcos'altro in un momento diverso dall'uso di quelle pagine di tmpfs.
52
user2394284

Ok, ecco la realtà.

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

Il tmpfs usa la memoria e lo swappace dato che è un backing store un filesystem usa una specifica area del disco, né è limitato nella dimensione del filesystem, è abbastanza possibile avere un tmpfs da 200GB su una macchina con meno di un GB di ram se hai uno swappace sufficiente.

La differenza è quando i dati vengono scritti sul disco. Per un tmpfs i dati vengono scritti SOLO quando la memoria diventa troppo piena oi dati improbabili da utilizzare a breve. I normali filesystem Linux OTOH sono progettati per avere sempre un insieme di dati più o meno consistente sul disco, quindi se l'utente tira la spina non perde tutto.

Personalmente, sono abituato ad avere sistemi operativi che non si bloccano e sistemi UPS (es: 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, ad eccezione del fatto che tratta i dati dell'utente come di seconda classe e non lo protegge. (ext3 è lo stesso ma non lo si nota a causa del checkpoint di 5 secondi)

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

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

NON usare mai/dev/shm.

A meno che non lo si stia usando per file molto piccoli (probabilmente mmap'd) IPC e si è certi che esiste (non è uno standard) e la macchina ha più memoria e swap disponibili.

18
Robert

Usa/tmp/per i file temporanei. Usa/dev/shm/quando vuoi la memoria condivisa (cioè, interprocesso della comunicazione attraverso i file).

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

4
Captain Segfault

Un altro momento 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 sul disco.

Un sistema di monitoraggio con cui ho familiarità ha bisogno di scrivere file temporanei mentre costruisce il proprio report per l'invio a un server centrale. È molto più probabile, in pratica, che qualcosa impedisca le scritture su un file system (o lo spazio su disco o un errore RAID sottostante ha spinto il sistema in una modalità di sola lettura dell'hardware), ma si sarà ancora in grado di zoppicare fino all'avviso su di esso che se qualcosa spirali 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 a RAM in modo da essere potenzialmente in grado di inviare un avviso su un disco completo o hardware morto/morente.

1
Japheth Cleaver

In Perl, avendo almeno 8 GB su qualsiasi macchina (tutti con Linux Mint), sono una delle buone abitudini a fare algoritmi complessi basati su DB_File (struttura dati in un file) con milioni di letture e scritture usando/dev/shm

In altre lingue, non avendo gigether ovunque, per evitare gli avviamenti e le interruzioni nel trasferimento di rete (lavorando localmente su un file che si trova su un server in un'atmosfera client-server), utilizzando un file batch di qualche tipo, copierò il intero (300-900 MB) di file in una sola volta su/dev/shm, eseguire il programma con output su/dev/shm, scrivere i risultati sul server ed eliminare da/dev/shm

Naturalmente, se avessi meno RAM, non lo farei. Normalmente, il file system in-memory di/dev/shm legge una dimensione pari alla metà della RAM disponibile. Tuttavia, l'uso normale di RAM è costante. Quindi non potresti davvero farlo su un dispositivo con 2 GB o meno. Per trasformare la parafrasi in un'iperbole, c'è spesso in RAM che anche il sistema non segnala bene.

0
David Grove

/ dev/shm viene utilizzato per i driver ei programmi di dispositivi 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 va raddoppiato, quindi se hai bisogno di più processi o thread per essere in grado di accedere a quella memoria in sicurezza.

Il fatto è che solo perché il driver usa 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.

0