kswapd0 займає 99,9% мого процесора, як показує мене, проблема з'явилася сьогодні, коли ігор, і вперше вона пішла через 6 хвилин, а зараз це займає близько 20 хвилин. Як це можна виправити і що це спричиняє?
kswapd0 займає 99,9% мого процесора, як показує мене, проблема з'явилася сьогодні, коли ігор, і вперше вона пішла через 6 хвилин, а зараз це займає близько 20 хвилин. Як це можна виправити і що це спричиняє?
Відповіді:
Процес kswapd0 - це процес, який управляє віртуальною пам'яттю. Ваша машина повинна мати оперативну пам’ять, SWAP та EXT4 на вашому HDD / SSD. У файлі ext4 зберігається все, і доступ до нього завжди повільніше, ніж оперативна пам'ять. Оперативна пам’ять - це як наполовину запущений простір для програм для швидкого доступу до інформації. Більшість комп'ютерів мають щонайменше 4 Гб оперативної пам’яті, що в нормальних умовах достатньо. Однак, граючи в гру, у вас може залишитися мало місця на оперативній пам’яті, куди входить SWAP.
SWAP - це підроблена оперативна пам’ять, розташована на вашому жорсткому диску / SSD поруч із EXT4. Доступ до нього швидший, ніж EXT4, але він набагато повільніше, ніж фактична ОЗУ. Коли у вас не вистачає пам'яті, kswapd0 переміщує програми, які ви не використовуєте / не використовуєте так само, як інші програми, до SWAP, що спричиняє надзвичайне відставання в цих процесах. Якщо вашій грі потрібна 5 Гб оперативної пам’яті, 1 ГБ в LEAST було б у SWAP. Це означає, що коли вона намагається отримати доступ до цієї інформації, їй потрібно чекати довше, щоб її отримати.
Весь цей процес викликає екстремальне використання процесора, переміщення інформації з SWAP та оперативної пам’яті та одночасно обробка запиту інформації. Як вирішити це питання?
Скажіть kswapd0, щоб переміщувати речі в SWAP лише тоді, коли ви повністю поза ОЗУ. Це єдиний найефективніший метод вирішення проблем SWAP. Біжи
echo vm.swappiness=0 | sudo tee -a /etc/sysctl.conf
де 0
залишився відсоток, від 100
якого слід використовувати SWAP (коли у вас залишилося 0% оперативної пам’яті, SWAP почне приймати дані). Ви також можете просто редагувати /etc/sysctl.conf на свій смак, замість того, щоб додавати цю команду в кінці її щоразу, використовуючи gedit або nano чи будь-що інше, не забудьте отримати sudo, хоча цей файл належить root. Перезавантажте і ваш встановлений!
Це найкраще, що ти можеш зробити. Інші можуть сказати, що вимкнути своп повністю, але це небезпечно, і я НЕ рекомендую цього. Це може призвести до замерзання всіх систем, якщо працює витік пам’яті або працює занадто багато додатків. Просто зрозумійте, що SWAP - це безпечна помилка для ОЗУ. Це, безумовно, не так швидко і ефективно, як оперативна пам’ять, але це краще, ніж вікно сторінки файлу Window! (що досягає тієї ж мети)
EDIT: Якщо вам цікаво дізнатися більше про SWAP, дивіться тут .
kwapd0
пішов. Дякую.
Мені це трапляється часом на Ubuntu 14.04 з ядром 3.19.0-50-generic (і раніше), що працює у VMware vm. Я не маю поняття, що змусило це з'явитися, але це відбувається під час простою.
top
показує:
# 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
перезавантаження вирішило проблему - тимчасово.
після відповіді на сервері за замовчуванням (kswapd часто використовує 100% ЦП, коли використовується swap) там, де ті самі налаштування в моїй системі:
# cat /proc/sys/vm/swappiness
60
# cat /proc/sys/vm/vfs_cache_pressure
100
# cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never
рішення було насправді # 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
тепер добре:
# 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
але оскільки фактична причина ще не відома, і я не опрацював жодного відповідного пояснення в мережі, це не є постійним рішенням. Власне, обрана відповідь могла б бути постійним рішенням. Я просто хотів додати це для подальшої довідки, оскільки перезавантаження (щоб зробити sysctl набуло чинності) не завжди можливо.
Іншим рішенням може бути встановлення THP на або madvice
або never
(див. Коментар Poige до його відповіді , як я можу змінити "/ sys / ядро / mm / transparent_hugepage / включено" та посилається посібник MongoDB на відключення прозорих величезних сторінок (THP) )
Я встановив наступну партію як роботу з cron як "постійне" рішення:
#!/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
посилається на
# m h dom mon dow command
* * * * * /bin/bash /path/to/batch/drop_caches.sh >> /var/log/syslog 2>&1