Soluzione 1:
kswapd gestisce lo spazio di swap in risposta a richieste di memoria superiori a quelle fisicamente disponibili per tutti processi.
È indipendente dal processo, è interessato solo a quali pagine sono accessibili e quando (ovviamente è più complesso di così, ma per semplificare le cose potremmo anche vederlo in questo modo).
Quindi il vero la domanda è "quali processi hanno il carico maggiore sulla memoria che fa sì che kswapd abbia bisogno di paginare tutto il tempo".
È più facile rispondere usando 'top' e passando alla modalità di ordinamento dell'utilizzo della memoria.
Soluzione 2:
Puoi scriverlo... ma puoi anche farlo tramite top
Corri in alto e premi O seguito da p quindi inserisci
Ora tutti i processi sono ordinati in base all'utilizzo dello swap e puoi vedere quali lo stanno utilizzando
Soluzione 3:
Se utilizzi Ubuntu 15.10 o versioni successive, questo potrebbe effettivamente essere il risultato di un bug, soprattutto se il tuo sistema è una macchina virtuale priva di una partizione di swap (ad esempio, AWS EC2). Il problema esiste su altre distribuzioni, ma, al momento della stesura, non è chiaro se la stessa correzione funzioni universalmente.
Una soluzione temporanea:
sudo ln -s /dev/null /etc/udev/rules.d/40-vm-hotadd.rules
sudo reboot
Tieni presente che questo disabiliterà l'aggiunta di RAM/CPU a caldo per le macchine virtuali Xen e Hyper-V.
Soluzione 4:
Sembra esserci anche un bug in kswapd da qualche parte, si spera solo su kernel più vecchi.
Quasi ogni giorno ora kswapd va in beserk in modo casuale su alcune macchine in un cluster più grande (con un kernel non aggiornato, però). CPU al 100% su entrambi i processi kswapd. Nessun altro processo in esecuzione (tranne la shell ssh), molta RAM libera (più di 700 MB) e nessuno SWAP utilizzato. No swapin, no swapout pure.
Nulla spiega ancora perché una particolare macchina viene colpita e un'altra no. Sembra non essere del tutto casuale, perché di solito colpisce più di una macchina in un breve lasso di tempo. Sembra che le macchine, che sono inattive, così come le macchine, che sono sotto alta pressione, siano meno (!) probabilmente colpite dall'effetto. Quindi deve fare qualcosa con il carico di lavoro e funziona solo se la macchina non è né inattiva né molto occupata.
Se il problema colpisce nulla aiuta più. Uccisione di tutti i processi (che non sono diventati irreversibili), smontaggio di tutti i filesystem, niente. kswapd rimane ancora al 100% della CPU. Sospetto una corsa agli spinlock nei kernel SMP, ma è anche probabile che mi sbagli.
Forse vedi la mia risposta serverfault.com/questions/316995/#493257
Note:
- Il riavvio delle macchine interessate spesso fallisce perché il processo di spegnimento inizia a bloccarsi da qualche parte.
- Non esiste una connessione diretta a Internet. Le cause estranee sono improbabili.
- Sembra dipendere dal tipo di carico di lavoro che le macchine elaborano dal punto di vista del carico, perché abbiamo macchine che non sono mai state interessate (ancora).
- Mi dispiace, non posso essere più specifico su cosa facciamo e perché.
- Sì, sto ipotizzando. Perché è un effetto estremamente sconcertante, oggi.