Come faccio a sapere quale processo sta causando l'utilizzo di kswapd?

23

Vedo kswapd che utilizza la CPU al 100% ... come posso sapere per quale processo kswapd viene utilizzato così tanto?

— Deshawn
fonte

1

Uhm. kswapd è il processo. Funziona per conto del kernel.

— mailq,

Vedi serverfault.com/questions/24124/…

— PT

2

@mailq ... sì, ma non sta sostituendo la memoria dello spazio utente? e in tal caso, come posso sapere quale memoria del processo sta scambiando in quel momento?

— Deshawn,

18

kswapd gestisce lo spazio di swap in risposta a richieste di memoria superiori a quelle fisicamente disponibili per tutti i processi.

È un processo agnostico, è interessato solo a quali pagine accedono e quando (è più complesso di questo ovviamente, ma per mantenere le cose semplici possiamo anche vederlo in questo modo).

Quindi la vera domanda è "quali processi hanno il più grande onere sulla memoria che sta facendo sì che kswapd abbia bisogno di sfogliare continuamente".

A questo si risponde più facilmente usando 'top' e passando alla modalità di ordinamento dell'utilizzo della memoria.

— Paolo
fonte

Grazie!. Skswapd si avvia SOLO quando le pagine toccate effettive superano quelle fisiche o si avvia anche se un processo ha allocato la memoria o mappato la regione SHM ma non l'ha utilizzata? Cioè, è solo quando si verifica il problema o tiene la contabilità e scambia le cose dentro e fuori anche se c'è memoria fisica disponibile ma solo perché alcuni processi sono stati inattivi, ecc.?

— Deshawn,

A quanto ho capito, in circostanze normali kswapd rimuoverà tutte le pagine dalla memoria principale che non hanno bisogno di essere lì, perché qualsiasi pagina che viene liberata può essere utilizzata per la memorizzazione nella cache o altri processi. Vale a dire, è meglio avere una vecchia pagina inutilizzata già sul disco piuttosto che sostenere il costo della lentezza nel spostarla in risposta a una richiesta di memoria da un altro processo.

— Paul

Anche se una macchina deve utilizzare molto spazio di swap, non dovrebbe richiedere il 100% di CPU per farlo. Qualcosa è strano.

— Zaz,

@Zaz Non è così tanto che sta usando la potenza di elaborazione della CPU per fare lo scambio, è che la CPU è utilizzata al 100% a causa di IOWAIT. Ogni volta che la memoria deve essere scambiata dal disco, la CPU deve stare lì e aspettare - IOWAIT, e non sta facendo altro (in media).

— Paul,

@Paul: sei sicuro? topmi sta dicendo che non viene speso tempo nell'attesa di IO e quasi il 100% del tempo viene impiegato nel sistema. Ulteriori informazioni: kswapd utilizza spesso la CPU al 100% quando si utilizza lo swap

— Zaz,

9

Puoi copiarlo .. ma puoi anche farlo tramite top

Esegui in alto, quindi 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

— Mike
fonte

2

O richiama le opzioni di filtro per me, premendo p poi invio mi dà "'manca' il delimitatore di filtro mancante"

— Shadow

@Shadow Stesso problema, qui un comando alternativo unix.stackexchange.com/questions/128953/…

— Björn il

8

Se utilizzi Ubuntu 15.10 o versioni successive, questo potrebbe essere il risultato 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 scrittura, non è chiaro se la stessa correzione funziona universalmente.

Una soluzione temporanea:

sudo ln -s /dev/null /etc/udev/rules.d/40-vm-hotadd.rules
sudo reboot

Notare che ciò disabiliterà la RAM / CPU hotadding per macchine virtuali Xen e Hyper-V.

— Zenexer
fonte

Se ne fosse uscito dal nulla sul mio sistema su Kubuntu 16.10 con la soluzione alternativa già abilitata qualche tempo fa.

— jeteon,

@jeteon Esistono diversi problemi che possono causare questo comportamento; questo sembra essere particolarmente comune.

— Zenexer,

Si. Ho scoperto che echo 3 > /proc/sys/vm/drop_cachesallevia una volta che inizia a succedere. Ho preventivamente il comando su un lavoro cron ora e sembra aiutare, o almeno limitare la durata del massacro di OOM quando sono lontano dal computer.

— jeteon,

6

Sembra anche che ci sia un bug in kswapd da qualche parte, si spera solo sui kernel più vecchi.

Quasi ogni giorno ora kswapd va a ruba in modo casuale su alcune macchine in un cluster più grande (con un kernel non corrente, però). CPU al 100% su entrambi i processi kswapd. Nessun altro processo in esecuzione (tranne la shell ssh), molta RAM libera (oltre 700 MB) e nessuno SWAP utilizzato. No swapin, no swapout pure.

Nulla spiega ancora, perché una determinata macchina viene colpita e un'altra no. Sembra non essere del tutto casuale, perché di solito colpisce più di una macchina in breve tempo. Sembra che le macchine che sono inattive, così come le macchine che sono ad alta pressione, siano meno (!) Probabilmente colpite dall'effetto. Quindi deve fare qualcosa con il carico di lavoro e colpisce solo se la macchina non è né inattiva né molto occupata.

Se il problema si risolve, nulla aiuta più. Uccidere tutti i processi (che non sono diventati invendibili), smontare tutti i filesystem, niente. kswapdrimane ancora al 100% della CPU. Ho il sospetto che ci sia una gara di spinlock nei kernel SMP, ma è anche probabile che mi sbagli.

Forse vedi la mia risposta serverfault.com/questions/316995/#493257

Gli appunti:

Il riavvio delle macchine interessate spesso non riesce perché il processo di arresto inizia a bloccarsi da qualche parte.
Non esiste una connessione diretta a Internet. Le cause straniere sono improbabili.
Sembra dipendere dal tipo di carico di lavoro che la macchina elabora dal punto di vista del carico, perché abbiamo macchine che non sono mai state interessate (ancora).
Spiacenti, non posso essere più specifico su ciò che facciamo e perché.
Sì, sto speculando. Perché è un effetto estremamente sconcertante, oggi.

— Tino
fonte

Questo è storico. RedHat ha confermato: si trattava di un problema del kernel 2.6.18-194.el5 in combinazione con il client NFS. È stato risolto nel 2012 già. Vedi la risposta collegata nel mio testo per qualche informazione in più. Se lo colpisci oggi, è probabilmente un'altra causa.

— Tino,

1

Questo è ancora un problema in alcuni punti. Ho visto tonnellate di questi pop-up. qui e qui ci sono alcuni esempi.

— trueCamelType