Qual è il valore appropriato di vm.swappiness quando si utilizza zram?

Sto usando zram sul mio computer come uno scambio compresso con supporto RAM. Quando il sistema deve scambiare qualcosa, scambiarlo in un file di scambio supportato da zram è più o meno equivalente a comprimere quei dati in memoria per liberare spazio. Questo rende lo scambio molto veloce per la maggior parte del tempo, rispetto allo scambio supportato da disco. Per questo motivo, mi chiedo se ci siano delle prestazioni da ottenere incoraggiando il sistema a sostituire le cose inutilizzate in modo più aggressivo, dal momento che può farlo senza colpire effettivamente il disco?

Quindi qualcuno ha fatto casino con, diciamo, impostando vm.swappinesssu 100 mentre si utilizza zram? Sarebbe desiderabile?

sysctl -w vm.swappiness=100

— Ryan C. Thompson
fonte

Questa è un'ottima domanda e penso che alcuni benchmark siano per rimuovere le opinioni e arrivare ai fatti ...

— Anziano Geek,

Buona idea, e zram potrebbe essere migliorato dal 2012 quando l'ho usato l'ultima volta :-)

— Huygens

Ho fatto un piccolo test e, per quanto ne so, la memoria "riservata" per zram è ancora usata come cache. Se questo è confermato, penso che potrebbe avere senso mantenere bassa la swappiness per evitare cicli di CPU?

— Vitor

Risposte:

Non consiglierei davvero di aumentare lo swappiness. Un meccanismo comune nel kernel è che metterà pagine (pezzo di memoria) nello scambio per liberare un po 'di memoria per altre attività in esecuzione.

Primo "problema" quando il kernel vuole che vengano liberate n pagine, m (con m <n, m è il numero di pagine compresse richieste per contenere n) sono appena create nella RAM, non sono sicuro che ciò possa disturbare il kernel o non.

Quindi comunque, quando si hanno pagine nello scambio, è possibile che si usi l'applicazione in seguito con alcune delle sue pagine nello scambio. Ciò che il kernel fa è riportare quelle pagine nella memoria fisica ma non rimuoverle dallo swap (che con lo swap standard può essere visto come cache , quindi quando l'applicazione torna in background, il kernel non deve riscrivere quelle pagine nello scambio lento). Tuttavia con zram non è forse un trucco saggio, perché hai in memoria le pagine m in zram + le pagine n che sono tornate in memoria!

Il kernel ha normalmente una "memoria totale" che può usare per fare i suoi affari. Quando aggiungi zram, sta contando solo nella memoria "swap", come sarebbe con qualsiasi swap basato su disco, ma ha ridotto la "memoria totale" effettiva e ciò non è previsto / anticipato dal kernel. A volte puoi avere comportamenti strani e non desiderati per questo!

Con zram, sarebbe bene che il kernel non si scambiasse troppo in quest'area quando è sotto pressione della memoria. E dovresti sempre avere una vera partizione di scambio del disco rigido più grande almeno della dimensione massima di zram, in modo che il sistema non ottenga OOM mentre allo stesso tempo vedresti molto spazio libero come riportato da free!

— Huygens
fonte

zram fornisce dispositivi di blocco RAM. Tutto ciò che è scritto su questi dispositivi a blocchi viene compresso. Se i dispositivi a blocchi zram vengono utilizzati come swap, quando il sistema tenta di spostare parti della memoria per scambiare, la memoria verrà effettivamente spostata da una parte della RAM a un'altra, tranne per il fatto che i dati verranno compressi prima di essere copiati nella destinazione. Questo funziona efficacemente come un meccanismo di compressione della memoria economico per migliorare la reattività nei sistemi con quantità limitate di memoria. ... Zram è stato in scena dal Linux 2.6.33. In 3.14 zram è stato spostato dalla messa in scena a drivers / block / zram.

— Elder Geek,

@ElderGeek esattamente! E prenderò un esempio per illustrare perché ciò non è perfetto. Il kernel tenterà di rimuovere 64 MB di RAM, inserendoli nello swap zram. Compresso il blocco da 64 MB è ora 32 MB. Il risultato è che la memoria è diminuita di 32 MB e non di 64 MB. Ora cosa succede quando l'applicazione richiede i 64 MB di memoria, il kernel copia (e non sposta) il pezzo di memoria. Ora hai 64 MB in RAM + 32 MB in zram. Perché copiare Perché il kernel memorizza nella cache le pagine come ho spiegato nella mia risposta. Entrambi i comportamenti non sono ideali. E quando la memoria non è ben comprimibile, è anche peggio.

— Huygens,

Ancora in fase di test. Penserei che ci debba essere un modo per ottimizzare l'algoritmo di memorizzazione nella cache che zram utilizza per liberare la pagina compressa quando viene copiata nuovamente nella RAM non compressa.

— Elder Geek

L'ho provato diverse volte fino al 2012. A quel tempo il mio computer era limitato a 1 GB di RAM e durante la navigazione in Internet era dolorosamente lento (di solito ho aperto 10-50 schede). Ma da allora non l'ho più usato. Ho abbastanza RAM che non uso più swap. Quando usavo zram con Firefox allora, ho iniziato rapidamente a "scambiare" data la poca RAM che avevo. E rapidamente ho avuto un sistema che non rispondeva con molti crash. Senza zram era dolorosamente lento ma almeno stabile. Il mio problema era che probabilmente comprimeva / decomprimeva costantemente le pagine di memoria.

— Huygens,

Sì, i miei risultati sono stati in qualche modo simili, su un sistema con 8 GB sono stato in grado di forzare una OOM avviando diverse macchine virtuali durante un processo di codifica. Hai qualche esperienza con zswap? Sembra una valida alternativa basata su ciò che ho letto.

— Elder Geek

Risposta breve: vm.swappiness=100è il valore appropriato per zram (almeno su Debian Stretch con Linux 4.9, credo che sia il miglior valore)

Ho già testato vm.swappiness=100per me.

Penso che tu possa fare qualche semplice test per accertarti quale valore sia il migliore per te.

Inoltre ho fatto un altro semplice programma per testare questa domanda. x Sulla mia macchina un vm.swappinessvalore molto basso (come vm.swappiness=1) causerà un evidente problema di reattività.

Circa SwapCachedin /proc/meminfo:

Innanzitutto, prova vm.page-cluster=0, questo forse può ridurre alcuni inutili SwapCacheddallo scambio.

SwapCached può velocizzare zram come un dispositivo di scambio non zram

SwapCached è possibile riutilizzare (gratuitamente) quando necessario:

./linux-4.9/mm$ grep -rn delete_from_swap_cache
memory-failure.c:715:   delete_from_swap_cache(p);
shmem.c:1115:       delete_from_swap_cache(*pagep);
shmem.c:1645:            * unaccounting, now delete_from_swap_cache() will do
shmem.c:1652:               delete_from_swap_cache(page);
shmem.c:1668:       delete_from_swap_cache(page);
vmscan.c:673:       __delete_from_swap_cache(page);
swap_state.c:137:void __delete_from_swap_cache(struct page *page)
swap_state.c:218:void delete_from_swap_cache(struct page *page)
swap_state.c:227:   __delete_from_swap_cache(page);
swapfile.c:947:         delete_from_swap_cache(page);
swapfile.c:987: delete_from_swap_cache(page);
swapfile.c:1023:            delete_from_swap_cache(page);
swapfile.c:1571:            delete_from_swap_cache(page);
./linux-4.9/mm$

— analfabeta
fonte

Le pagine devono essere scambiate (su disco) quando la memoria è piena. Se stai usando la memoria per creare il posto dove scambiare le pagine quando la memoria è piena, si potrebbe pensare che batte lo scopo, tranne se la compressione fa la differenza (e quindi sarebbe naturale comprimere la memoria direttamente invece di passare attraverso scambiare). Immagino che si dovrebbe fare un benchmark, dato che i computer sono sempre più veloci nel comprimere e decomprimere rispetto alla velocità della memoria.

— Alessandro
fonte

Ho trovato lo swap supportato da zram stesso abbastanza utile quando il sistema sta esaurendo la memoria. Mi ha salvato alcune volte dall'essere completamente bloccato nello scambio dell'inferno e nel dover ricominciare (sto analizzando grandi set di dati, quindi ho bisogno della memoria, tutti i 24 GB di esso). Mi chiedo solo se il vm.swappinessvalore è ottimizzato per lo scambio supportato da disco e se dovrei modificarlo se utilizzerò principalmente lo scambio supportato da zram.

— Ryan C. Thompson,

"sempre più veloce"? La compressione al volo ha funzionato meglio dell'I / O diretto su disco da oltre un decennio (non sarà mai più veloce dell'accesso alla memoria - non è questo il punto)

— symcbean

symcbean, hai dimenticato "rispetto alla velocità della memoria". Dov'è il disaccordo?

— Alexander

Penso che il punto di vista di symcbean sia che l'obiettivo delle pagine di backup della memoria compressa (zram) sia quello di sostituire lo scambio con un supporto fisico. Il motivo per cui non è "naturale comprimere direttamente la memoria" è perché sarebbe complicato per le applicazioni dover determinare quali parti della sua memoria potrebbero essere compresse e quando; il sottosistema VM è un posto molto più semplice per implementarlo. I carichi di lavoro che beneficiano di zram hanno pagine che non si trovano nel set di lavoro e possono essere facilmente compresse.

— Daniel Papasian,