kswapd0 działa na 99,9% jednego procesora, ale tak naprawdę wcale nie zamienia
Dla mnie zdarza się to czasami na Ubuntu 14.04 z jądrem 3.19.0-50-generic (i wcześniejszym) uruchomionym w VMware vm. Nie mam pojęcia, co sprawiło, że się pojawił, ale pojawia się w czasie bezczynności.
top przedstawia:
# 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
Rozwiązanie tymczasowe
ponowne uruchomienie rozwiązało problem - tymczasowo.
po odpowiedzi na błąd serwera (kswapd często używa 100% procesora, gdy używana jest funkcja swap) tam, gdzie te same ustawienia w moim systemie:
# cat /proc/sys/vm/swappiness
60
# cat /proc/sys/vm/vfs_cache_pressure
100
# cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never
rozwiązaniem było w rzeczywistości # 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
teraz jest w porządku:
# 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
Stałe rozwiązanie (do znalezienia)?
ale ponieważ faktyczny powód nie jest jeszcze znany, a ja nie podałem żadnego odpowiedniego wyjaśnienia w sieci, nie jest to trwałe rozwiązanie. Właściwie wybrana odpowiedź może być trwałym rozwiązaniem. Chciałem tylko dodać to do przyszłego odwołania, ponieważ ponowne uruchomienie (aby sysctl zadziałało) nie zawsze jest możliwe.
Innym rozwiązaniem może być ustawienie THP na jeden madvicelub never(patrz komentarz poige'a do jego odpowiedzi : Jak zmodyfikować „/ sys / kernel / mm / transparent_hugepage / enabled” oraz przywołany Podręcznik MongoDB na temat wyłączania przezroczystych ogromnych stron (THP) )
praca crona
skonfigurowałem następującą partię jako zadanie CRON jako „trwałe” rozwiązanie:
#!/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
przywołany z
# m h dom mon dow command
* * * * * /bin/bash /path/to/batch/drop_caches.sh >> /var/log/syslog 2>&1
16.04 14.04 zamiana