Come disabilitare completamente lo swap?

Sto usando Debian Sid, disco rigido formattato con ext4, in esecuzione su Linux 3.1

Ricordo che nelle versioni precedenti di Linux (forse prima della 3.0), se esaurivo la memoria e lo scambio non è abilitato, i programmi di solito si bloccano. Questo è perfetto per il mio ambiente: navigazione web semplice senza operazioni critiche. Cioè, se mi imbatto in un sito Web errato che utilizza troppa memoria, si blocca senza rendere inutilizzabile il mio terminale.

Ma nella mia configurazione attuale, il computer si blocca con un throughput I / O violento in background. iotop rivela che kswapd0 è il colpevole, il che significa che è dovuto allo scambio. Dopo aver usato swapon -sper determinare eventuali swap abilitati, ho usato swapoff -aper disabilitare tutti gli swap e di swapon -snuovo per confermare che tutti gli swap erano disabilitati.

Quindi ho provato di nuovo a massimizzare l'utilizzo della memoria. Purtroppo, il comportamento che mi aspettavo non si è verificato. Al contrario, kswapd0 prova ripetutamente a scambiare la RAM e fallisce perché non c'è spazio di scambio. Poiché non si arrende mai, il mio computer è bloccato in un eterno blocco I / O pesante, dannoso per la salute del mio disco.

Sto facendo qualcosa di sbagliato nel tentativo di farlo swapoff -a? Perché il comportamento è diverso da quello che era (probabilmente prima della 3.0)?

La disabilitazione dello swap non farà ciò che desideri. Otterrai comunque un throughput I / O violento, ma sarà di pagine pulite piuttosto che sporche.

Senza scambio, il sistema comprimerà la cache di pagine pulite (non modificate) quasi a zero, poiché quelle sono le uniche pagine che è possibile eliminare dalla memoria fisica. Può solo sfrattare pagine sporche (modificate) dalla memoria scrivendole per scambiare, senza scambio, non ha modo di sfrattare pagine sporche.

Man mano che la memoria fisica si esaurisce, ogni processo dovrà caricare le sue tabelle codici dal disco mentre elimina le tabelle codici precedenti. Il risultato sarà un thrashing violento e un lavoro eccessivo svolto dal sottosistema di scambio.

Questo è un caso speciale di un principio molto importante: per un sistema ben progettato, non è possibile farlo funzionare meglio riducendo le sue scelte. Linux è un sistema ben progettato. La rimozione dello swap offre solo un minor numero di scelte, quindi non sorprende che si comporti peggio.

Una soluzione migliore rispetto alla disattivazione dello swap, che nella migliore delle ipotesi causerà l'interruzione di processi casuali quando la memoria si esaurisce, consiste nell'impostare il limite del segmento di dati per processo per i processi che rimuovono le cose dalla rete. In questo modo un browser in fuga colpirà il limite e morirà, anziché rendere inutilizzabile l'intero sistema. Esempio, dalla shell

(ulimit -d 400000; firefox) &

Il numero dopo -d è in kilobyte. Dovresti provare questo sul tuo sistema per scegliere il valore migliore per le tue abitudini di navigazione. Le parentesi causano la creazione di una subshell; il comando ulimit influenza solo quella shell e i suoi figli, isolandone gli effetti dalla shell madre.

Per assicurarti che lo swap non venga utilizzato, ti conviene evitare che qualsiasi swap venga aggiunto all'avvio. Questo può essere fatto, a seconda del sistema, disabilitando il swapservizio di avvio o semplicemente commentando la voce di scambio in /etc/fstab.

Per quanto riguarda il tuo hangup, la stop()funzione in /etc/init.d/swappotrebbe dare un indizio:

stop()
{
       ebegin "Deactivating swap devices"

       # Try to unmount all tmpfs filesystems not in use, else a deadlock may
       # occure. As $RC_SVCDIR may also be tmpfs we cd to it to lock it
       cd "$RC_SVCDIR"
       umount -a -t tmpfs 2>/dev/null

       case "$RC_UNAME" in
               NetBSD|OpenBSD) swapctl -U -t noblk >/dev/null;;
               *)              swapoff -a >/dev/null;;
       esac
       eend 0
}

Notare la parte su deadlock . Puoi provare a fare umount -a -t tmpfste stesso prima di disattivare lo scambio.

Modificare:

Probabilmente, potresti anche raggiungere il tuo obiettivo modificando le sysctlimpostazioni (vedi questa domanda ).

È meglio commentare la voce della partizione di swap /etc/fstabpiuttosto che eseguirla swapoff -adopo ogni avvio.

Ho lo stesso problema con kswapd0 sul mio hardware.

L'ottimizzazione del vm.swappinessparametro di sistema non mi aiuta.

sysctl -w vm.swappiness=0

Ho cercato su Google e letto molti post, mailing list e ora penso che questo sia un bug del kernel.

Quando non c'è alcuna partizione di swap attiva e la memoria libera diventa inferiore a qualche soglia (circa 300 MB nel mio caso) il sistema non risponde a causa della follia di kswapd0.

Probabilmente è riprodotto con una configurazione e condizioni speciali.

Per qualcuno è risolto dalla reinstallazione del sistema con il partizionamento per gli altri creando kernel personalizzati con kswapd0disabilitato.

Sul mio sistema (debian sid 2016-11-15), ho fatto questo:

1. disabilita subito lo swap:

   swapoff -a
   

2. commentare la riga con la partizione di swap in / etc / fstab

   #### #UUID=c6ddbc95-3bb5-49e1-ab25-b1c505e5360c none            swap    sw              0       0
   

3. disabilitare il montaggio di swap in systemd:

   systemctl --type swap
   systemctl stop dev-sda6.swap
   systemctl mask dev-sda6.swap
   

Sarebbe abbastanza. C'è riferimento allo scambio nel /etc/initramfs-tools/conf.d/resumefile. Non so quale sia lo scopo di questo. Forse questo file sarà un problema al prossimo riavvio (non provo ancora a riavviare, il mio tempo di attività è prezioso;)).

il computer si blocca con un throughput I / O violento in background. iotop rivela kswapd0 come colpevole

Ho trovato un modo (finora) per evitarlo. Se vuoi testarlo e vedere come funziona sul tuo sistema, vedi la patch del kernel all'interno di questa domanda . Fondamentalmente, non sfrutta le Active(file)pagine (almeno) quando è sotto pressione della memoria, quindi il thrashing del disco (lettura costante) è ridotto a quasi nulla e OOM-killer può essere attivato entro 1 secondo, invece di congelare il sistema operativo per quello che sembra come permanentemente (o almeno per molti minuti). Spero che i programmatori reali (di cui non sono) migliorino la patch e la trasformino in una soluzione reale, ora che vedono che ciò che fa funziona in queste situazioni.