Firefox использовал много памяти, и машина почти полностью остановилась из-за kswapd / kworker, использующего большинство процессоров. Нет места подкачки, и vm.swappiness= 0 в Linux 4.5.7 (Fedora 24).
Чего я не понимаю, так это того, что с почти 1,5 ГБ буфера / кеша, почему Linux не использовал этот кеш для Firefox / плагина-контейнера? Что делает kswapd?
top - 13:17:15 up 2:47, 4 users, load average: 9.78, 5.38, 2.35
Tasks: 197 total, 4 running, 193 sleeping, 0 stopped, 0 zombie
%Cpu(s): 5.8 us, 47.0 sy, 0.0 ni, 10.0 id, 36.9 wa, 0.0 hi, 0.3 si, 0.0 st
KiB Mem : 3922860 total, 105508 free, 2353620 used, 1463732 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 6828 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
49 root 20 0 0 0 0 R 100.0 0.0 2:35.25 kswapd0
6395 kevin 20 0 1152968 371132 4292 R 31.7 9.5 3:16.59 plugin-containe
3449 root 20 0 0 0 0 S 26.3 0.0 0:24.49 kworker/u16:3
5885 root 20 0 0 0 0 S 23.8 0.0 0:34.12 kworker/u16:2
4246 root 20 0 0 0 0 S 22.9 0.0 0:42.11 kworker/u16:4
6236 root 20 0 0 0 0 R 19.0 0.0 0:38.84 kworker/u16:1
4700 root 20 0 0 0 0 S 17.8 0.0 0:40.57 kworker/u16:5
3473 kevin 20 0 1662688 402008 460 D 8.3 10.2 7:36.45 thunderbird
1846 elastic+ 20 0 4238960 401324 124 S 5.7 10.2 3:05.58 java
6107 kevin 20 0 2133616 602096 20920 S 5.1 15.3 4:03.21 firefox...
Я не думаю, что в последнее время делал что-либо, связанное с вводом-выводом и записью, поэтому я не ожидал бы сброса грязных страниц на диск (SSD), хотя ожидание составляет 37%, что немного удивительно. Я взял около 30 секунд top и buff/cache не сильно изменилось, поэтому я не думаю, что на самом деле он сбрасывает какие-либо страницы на диск (хотя тогда я не понимаю, почему высокий% ожидания):
$ grep -e "top -" -e "buff/cache" top.txt
top - 13:17:11 up 2:47, 4 users, load average: 9.41, 5.23, 2.29
KiB Mem : 3922860 total, 103468 free, 2353456 used, 1465936 buff/cache
top - 13:17:15 up 2:47, 4 users, load average: 9.78, 5.38, 2.35
KiB Mem : 3922860 total, 105508 free, 2353620 used, 1463732 buff/cache
top - 13:17:21 up 2:47, 4 users, load average: 10.44, 5.59, 2.43
KiB Mem : 3922860 total, 108700 free, 2354532 used, 1459628 buff/cache
top - 13:17:24 up 2:47, 4 users, load average: 10.72, 5.73, 2.50
KiB Mem : 3922860 total, 107004 free, 2355112 used, 1460744 buff/cache
top - 13:17:43 up 2:47, 4 users, load average: 12.64, 6.39, 2.77
KiB Mem : 3922860 total, 108264 free, 2352820 used, 1461776 buff/cache
top - 13:17:46 up 2:47, 4 users, load average: 12.27, 6.42, 2.79
KiB Mem : 3922860 total, 108580 free, 2352584 used, 1461696 buff/cache
Убийство firefox и plugin-container вернул систему в норму. Я бы предпочел, чтобы либо кеш был полностью очищен, чтобы дать больше свободного места, либо, по крайней мере, чтобы убийца OOM работал в этом состоянии вместо того, чтобы делать Ctrl+Alt+F2 потому что KDE не отвечает, целую вечность ждет приглашения на вход и, наконец, выполняет pkill.
Это вопрос суперпользователя, а не serverfault, но у меня сам был на Fedora 24.
Это было вызвано ffmpeg-libs, VDPAU и моим GPU / ядром. Для меня я отключил VDPAU в VLC, чтобы «исправить» это.
Он выглядит как постоянно увеличивающийся размер Шмема в /proc/meminfo и затронутый процесс, если вы pmap он показывает сотни сопоставлений для 'renderD128' и постоянно увеличивается.
Скорее всего, это ошибка реализации - отключите вывод VDPAU в ваших приложениях для обработки видео.