kswapd0 забирает 99,9% моего процессора, как показывает топ, проблема возникла сегодня, когда игра и впервые ушла через 6 минут, а теперь она делает это около 20 минут. Как это поправимо и чем это вызвано?
kswapd0 забирает 99,9% моего процессора, как показывает топ, проблема возникла сегодня, когда игра и впервые ушла через 6 минут, а теперь она делает это около 20 минут. Как это поправимо и чем это вызвано?
Ответы:
Процесс kswapd0 - это процесс, управляющий виртуальной памятью. Ваша машина должна иметь ОЗУ, SWAP и EXT4 на жестком диске / SSD. В ext4 хранится все, и доступ к нему всегда медленнее, чем в ОЗУ. Оперативная память - это промежуточное пространство для быстрого доступа программ к информации. Большинство компьютеров имеют как минимум 4 ГБ ОЗУ, что в обычных условиях вполне достаточно. Тем не менее, играя в игру, вы можете нехватать места в ОЗУ, в которое входит SWAP.
SWAP - это фальшивое ОЗУ, расположенное на вашем жестком диске / SSD рядом с EXT4. Доступ к нему быстрее, чем к EXT4, но гораздо медленнее, чем к реальной памяти. Когда у вас заканчивается память, kswapd0 перемещает программы, которые вы не используете / не используете так же, как другие программы, в SWAP, что вызывает крайнюю задержку в этих процессах. Если вашей игре требовалось 5 ГБ ОЗУ, 1 ГБ по крайней мере было бы в SWAP. Это означает, что когда он пытается получить доступ к этой информации, он должен ждать дольше, чтобы получить ее.
Весь этот процесс вызывает чрезмерное использование ЦП, перемещение информации из и в SWAP и RAM и одновременную обработку запроса информации. Как решить эту проблему?
Скажите 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 является отказоустойчивым для оперативной памяти. Это определенно не так быстро и эффективно, как ОЗУ, но лучше, чем Pagefile в Windows! (которая выполняет ту же цель)
РЕДАКТИРОВАТЬ: Если вы заинтересованы в получении дополнительной информации о 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
перезагрузка решила проблему - временно.
после ответа на serverfault (kswapd часто использует 100% CPU, когда используется 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 / ядро / мм / transparent_hugepage / включено» и ссылки MongoDB Руководство по Disable Transparent Huge Страницы (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