Usando tmpfs + una partizione di swap molto grande per / tmp invece di un normale filesystem?

Ho un server Linux e ho una partizione del disco da 500 GB di riserva. Volevo formattarlo e usarlo per / tmp. Il server occasionalmente esegue alcune grandi attività di elaborazione dei dati, quindi può succedere che / tmp conterrà GB di dati temporanei.

Poi ho avuto l'idea che invece avrei potuto aggiungerlo come partizione di swap e montare / tmp su tmpfs. Questa idea è ragionevole?

Il server ha 6 GB di RAM, quindi nella maggior parte dei casi i dati su / tmp sarebbero solo nella RAM, con l'ovvio vantaggio di velocità. La domanda è: cosa succede se ci saranno 10-20 GB di dati su / tmp, come funzionerà il sistema? Quali sarebbero le prestazioni rispetto ad avere semplicemente / tmp montato su una partizione ext4? Grazie per l'aiuto.

Modifica: è chiaro che il sistema inizierà a scambiare memoria quando l'utilizzo di tmpfs raggiunge il limite di RAM. Ma Linux è abbastanza intelligente da scambiare dati tmpfs e mantenere dati "regolari" nella RAM? Se sì, allora suppongo che potrebbe comportarsi in modo ragionevole. In caso contrario, l'intero sistema sarà gravemente interessato.

Questa NON è una buona idea ^TM .

Starai bene con una grande /tmppartizione, montata in questo modo (dalla tua /etc/fstab)

tmpfs  /dev/tmp  tmpfs  defaults,nosuid,nodev,noexec,noatime,nodiratime,size=6000M 0 0

E potresti aggiungere il tuo disco esterno come una gigantesca partizione di swap

/dev/sdb1  swap  swap  defaults  0 0

Quando questo raggiunge il suo limite, la macchina inizierà a scambiare le pagine dalla RAM al disco: a quel punto, le medie di carico passeranno attraverso il tetto e la macchina si fermerà.

È una cattiva idea fare affidamento su SWAP in qualsiasi modo, sarebbe meglio vendere il tuo disco da 500 GB e semplicemente acquistare più RAM - è economico.

In sintesi

Se vuoi davvero usare il tuo disco da 500 GB, puoi montare il tuo disco da 500 GB /tmpcon un filesystem non journaled con atime e diratime disabilitati (es. ext2). Questo sarebbe sostanzialmente più veloce che fare con una macchina che è SWAPing

Questa potrebbe essere un'idea ragionevole.

L'inserimento di un vero filesystem su / tmp comporta costi generali, poiché i filesystem sono molto lunghi per assicurarsi che i dati sul disco non vengano danneggiati in caso di errore del sistema. Per un / tmp che viene pulito all'avvio, ovviamente è solo un sovraccarico. L'uso di un tmpfs eviterebbe questo sovraccarico.

D'altro canto, i filesystem si assicurano anche che i file siano organizzati sul disco in modo da ottimizzare i tempi di accesso, ovvero eviteranno la frammentazione. I tipici accessi sequenziali ai file comporteranno (principalmente) accessi sequenziali al disco, che sono più efficienti degli accessi casuali. Questo effetto è più pronunciato sulla rotazione dei dischi rigidi rispetto a SSD. La combinazione swap + tmpfs non può farlo facilmente, perché swap non è a conoscenza di quale pezzo di memoria appartiene a quale file e tmpfs non è a conoscenza di come le pagine sono mappate sulla memoria fisica o sul disco. Per file di grandi dimensioni, tuttavia, dovrebbe funzionare bene, poiché sia ​​tmpfs che swap cercano di mantenere le cose contigue in quel caso. Almeno, purché ci sia molto spazio libero su swap (altrimenti entra in gioco la frammentazione) e le scritture avvengono abbastanza lentamente da avere la possibilità di essere scambiate.

Quindi la linea di fondo è: dipende, dovresti provare entrambe le opzioni per vedere quale funziona meglio.

Quando montate i tmpfs, ricordatevi di impostare esplicitamente la dimensione. L'impostazione predefinita è metà della RAM fisica, quindi solo 3 GB.

Questa è in realtà una buona idea quando di solito non si hanno molti dati /tmp, ma a volte si consumano infiniti gigabyte per una durata limitata. Il problema è che il sistema di scambio di Linux non sa abbastanza del tuo caso d'uso per farlo bene. Generalmente darà la priorità al dumping o allo scambio della cache sulle pagine del programma, ma ciò non è di grande aiuto. Potrebbe essere possibile utilizzare i cgroup per raggiungere il tuo obiettivo, è quando i dati di scratch sono conservati nella memoria del programma, ma in questo caso non sono sicuro di come configurare i cgroup (suppongo che potresti usare un tmpfs FUSE ...) . Fortunatamente, questo non è richiesto. È possibile ottenere il comportamento desiderato con zram e un dispositivo di supporto.

zram-initè il programma che automatizza la configurazione di zram, che è un dispositivo compresso a blocchi di ram. Di solito c'è un esempio nella zram-initconfigurazione per il montaggio /tmpcome zram. Sarà qualcosa di simile al seguente

type0=/tmp
flag0= 
size0=524288 # 500G of logical space
mlim0=2G # 2G of memory
back0=/dev/loop0 # (or /dev/sdxN, your large slow drive)
notr0= 
maxs0=4 # maximum number of parallel processes for this device
algo0=zstd 
labl0=tmp # the label name
uuid0= 
args0= 

Questo comprimerà e memorizzerà in memoria tutto ciò che è scritto su / tmp. La compressione abituale è da qualche parte intorno al 50%. Consumerà al massimo 2G di memoria fisica. Se la memoria fisica si esaurisce, prenderà i file più vecchi e li spingerà nel dispositivo di backup, ancora compressi. Si noti che comporta un sovraccarico della CPU per comprimere e decomprimere i file, ma questo è generalmente compensato dall'IO ridotto.

Una configurazione simile può essere utilizzata insieme ai cgroups per consentire a determinati processi di scambiarsi senza influire negativamente sulle prestazioni complessive del sistema.