kswapd0 sta prendendo il 99,9% della mia CPU come mostra top, il problema è apparso oggi durante il gioco e la prima volta è scomparso dopo 6 minuti e ora lo fa da circa 20 minuti. Come è risolvibile e cosa sta causando questo?
kswapd0 sta prendendo il 99,9% della mia CPU come mostra top, il problema è apparso oggi durante il gioco e la prima volta è scomparso dopo 6 minuti e ora lo fa da circa 20 minuti. Come è risolvibile e cosa sta causando questo?
Risposte:
Il processo kswapd0 è il processo che gestisce la memoria virtuale. La tua macchina dovrebbe avere RAM, SWAP e EXT4 sul tuo HDD / SSD. Ext4 è dove tutto è archiviato ed è sempre più lento l'accesso rispetto alla RAM. La RAM è come uno spazio di esecuzione a metà strada per consentire ai programmi di accedere rapidamente alle informazioni. La maggior parte dei computer ha almeno 4 GB di RAM, che in condizioni normali è abbondante. Quando si gioca, tuttavia, è possibile che lo spazio nella RAM sia insufficiente, che è dove entra SWAP.
SWAP è una RAM falsa situata sul tuo HDD / SSD accanto a EXT4. L'accesso è più rapido rispetto a EXT4, ma è molto più lento della RAM effettiva. Quando si esaurisce la memoria, kswapd0 sposta i programmi che non si utilizzano / non si utilizzano tanto quanto gli altri programmi sullo SWAP, causando un ritardo estremo su tali processi. Se il tuo gioco avesse bisogno di 5 GB di RAM, almeno 1 GB sarebbe in SWAP. Ciò significa che quando tenta di accedere a tali informazioni, deve attendere più tempo per ottenerle.
L'intero processo causa un utilizzo estremo della CPU, spostando le informazioni da e verso SWAP e RAM e gestendo contemporaneamente la richiesta di informazioni. Come risolvere questo problema?
Di 'a kswapd0 di spostare le cose su SWAP solo quando sei completamente a corto di RAM. Questo è il metodo più efficace per risolvere i problemi SWAP. Correre
echo vm.swappiness=0 | sudo tee -a /etc/sysctl.conf
dove 0
è la percentuale lasciata fuori dalla 100
quale dovrebbe essere usato SWAP (quando hai ancora 0% di RAM, SWAP inizierà ad acquisire i dati). Puoi anche modificare /etc/sysctl.conf a tuo piacimento invece di aggiungere questo comando alla fine di esso ogni volta che usi gedit o nano o qualsiasi altra cosa, assicurati di sudo, questo file è di proprietà root. Riavvia e sei pronto!
Questo è il meglio che puoi fare. Altri potrebbero dire disabilitare completamente lo swap, ma è pericoloso e NON lo consiglierei. Ciò può causare il congelamento di interi sistemi in caso di perdita di memoria o di troppe applicazioni in esecuzione. Basta capire che lo SWAP è un fail-safe per la RAM. Non è sicuramente veloce o efficiente come la RAM, ma è meglio del file di paging di Windows! (che raggiunge lo stesso scopo)
EDIT: se sei interessato a saperne di più su SWAP, vedi qui .
kwapd0
è finito. Grazie.
A me succede a volte su Ubuntu 14.04 con kernel 3.19.0-50-generico (e precedenti) in esecuzione in un VMware VM. Non ho idea di cosa l'abbia fatto apparire, ma arriva durante i periodi di inattività.
top
Spettacoli:
# top
top - 09:49:35 up 5 days, 18:35, 1 user, load average: 1.00, 1.00, 0.99
Tasks: 219 total, 2 running, 217 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 25.0 sy, 0.0 ni, 74.7 id, 0.2 wa, 0.0 hi, 0.1 si, 0.0 st
KiB Mem: 3028784 total, 1874468 used, 1154316 free, 1010276 buffers
KiB Swap: 15624188 total, 3032 used, 15621156 free. 234928 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
52 root 20 0 0 0 0 R 99.7 0.0 122:15.21 kswapd0
3 root 20 0 0 0 0 S 0.3 0.0 0:29.86 ksoftirqd/0
7 root 20 0 0 0 0 S 0.3 0.0 9:49.47 rcu_sched
un riavvio risolto il problema - temporaneamente.
seguendo la risposta su serverfault (kswapd usa spesso la CPU al 100% quando si usa lo swap) dove si trovano le stesse impostazioni sul mio sistema:
# cat /proc/sys/vm/swappiness
60
# cat /proc/sys/vm/vfs_cache_pressure
100
# cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never
la soluzione era in realtà # echo 1 > /proc/sys/vm/drop_caches
:
# cat /proc/sys/vm/drop_caches
0
# echo 1 > /proc/sys/vm/drop_caches
# cat /proc/sys/vm/drop_caches
1
ora va bene:
# top
top - 10:08:58 up 5 days, 18:55, 1 user, load average: 0.72, 0.95, 0.98
Tasks: 220 total, 1 running, 219 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 0.2 sy, 0.0 ni, 99.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 3028784 total, 681704 used, 2347080 free, 2916 buffers
KiB Swap: 15624188 total, 3032 used, 15621156 free. 81924 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
9 root 20 0 0 0 0 S 0.3 0.0 14:10.40 rcuos/0
1 root 20 0 45652 8124 2888 S 0.0 0.3 1:54.98 init
ma poiché il vero motivo non è ancora noto e non ho trovato alcuna spiegazione adeguata in rete, questa non è una soluzione permanente. In realtà, la risposta selezionata potrebbe essere la soluzione permanente. Volevo solo aggiungere questo per riferimento futuro, poiché un riavvio (per rendere effettivo sysctl) non è sempre possibile.
Un'altra soluzione potrebbe essere quella di impostare THP su uno madvice
o never
(vedere il commento di poige alla sua risposta , Come posso modificare “/ sys / kernel / mm / transparent_hugepage / enabled” e il manuale MongoDB di riferimento su Disable Transparent Huge Pages (THP) )
ho impostato il seguente batch come cron job come soluzione "permanente":
#!/bin/bash
## run as cron, thus no $PATH, thus need to define all absolute paths
top=/usr/bin/top
grep=/bin/grep
top=$($top -bn1 -o \%CPU -u0 | $grep -m2 -E "%CPU|kswapd0")
IFS='
'
set -f
i=0
for line in $top
do
#echo $i $line
if ! (( i++ ))
then
pos=${line%%%CPU*}
pos=${#pos}
#echo $pos
else
cpu=${line:(($pos-1)):3}
cpu=${cpu// /}
#echo $cpu
fi
done
[[ -n $cpu ]] && \
(( $cpu >= 90 )) \
&& echo 1 > /proc/sys/vm/drop_caches \
&& echo "$$ $0: cache dropped (kswapd0 %CPU=$cpu)" >&2 \
&& exit 1
exit 0
invocato con
# m h dom mon dow command
* * * * * /bin/bash /path/to/batch/drop_caches.sh >> /var/log/syslog 2>&1