kswapd часто использует 100% ЦП, когда подкачка используется

Если у Вас есть сервис, работающий в докере как кукольник (хром бездисплейный API) В Вашем dockerfile добавляют немой-init .

При выполнении Докера> = 1.13.0 выполнений докера использования - init аргумент для жатвы процессов-зомби

docker run container --init

, Если Вы выполняете < =1.13.0 в немом-init использовании докера. Добавьте это к своему Dockerfile.

ADD https://github.com/Yelp/dumb-init/releases/download/v1.2.0/dumb-init_1.2.0_amd64
/usr/local/bin/dumb-init
RUN chmod +x /usr/local/bin/dumb-init
ENTRYPOINT ["dumb-init", "--"]

( Это квазиответ - слишком длинный, чтобы быть комментарием, но еще не готовый ответ )

1) Как насчет использования не 6G, а меньше , скажем, 1 или 2 ГиБ (вы можете установить размер с помощью mkswap без изменения размера раздела подкачки) - пробовали? Какие результаты?

2) Что такое sysctl vm.swappiness , sysctl vm.vfs_cache_pressure ?

3) Что такое cat / sys / kernel / mm / transparent_hugepage / включен ?

N. Б. Вы понимаете, что значительно изнашиваете свой SSD при такой настройке (не так много оперативной памяти, огромный своп).

P. S. Я мог бы порекомендовать попробовать использовать UltraKSM, но это требует исправления ядра. У меня есть несколько собственных сборок (на основе в реальном времени и BFS ), но они для систем на основе .deb , и тем временем их можно использовать на разных системах довольно легко (обычно вам нужно просто распаковать файлы .deb и создать соответствующие initrd / initramfs, это может быть проблемой для людей, не слишком знакомых с этой стороной Linux)

( продолжение следует)

Кажется, относительно общая проблема

Когда проблема возникает, можете ли вы проверить, останавливает ли ее выполнение следующей команды: echo 1 > / proc / sys / vm / drop_caches

Если это работает, вы можете запланировать его как периодическое задание cron в качестве временного решения.

Ядро kswap используется для выделения и освобождения временных страниц, если ваш своп используется, вы видите, что потоки ядра используют так много времени процессора, что можно было бы сказать, что потоки ядра kswap сканируют страницы памяти для перестановки некоторых страниц и обслуживания запроса на выделение памяти.

Я думаю, что удаление кеша в этом случае не помогает, потому что ядро ​​автоматически восстанавливает кеш, когда ОС ограничена в памяти.

Если вы этого не сделаете, есть проблемы с памятью и используйте команду free , вы получите столько памяти, используемой в качестве кеша, но если у вас есть проблема с памятью, Linux уменьшит кеш для обслуживания запросов на выделение памяти без необходимости отбрасывать cache

вы можете использовать sar -B и искать значения majft и pgscank , для других значений man sar

У меня C720 работает под управлением Linux Kernel 4.4.0 на Ubuntu 14.04.1 LTS с 2 ГБ ОЗУ и 2 ГБ подкачки .

Предполагая интенсивное использование Chrome / Chromium, вот несколько способов повысить производительность вашей системы:

1. Отредактируйте / etc / default / grub и добавьте следующие параметры ядра в GRUB_CMDLINE_LINUX_DEFAULT строка:
   • elevator = noop
   • zswap.enabled = 1
   • transparent_hugepage = madvise
2. Запустите sudo update-grub2 .
3. Отредактируйте /etc/sysctl.conf и добавьте следующее:
   • vm.swappiness = 25 # ~ max (RES в top ) * 2 / RAM = 500 МБ / 2 ГБ
   • vm.vfs_cache_pressure = 1000 # безопаснее, чем периодически удаление кешей
4. Перезагрузка.

Вы можете проверить изменения следующим образом:

$ dmesg | grep -i noop
[    0.694680] io scheduler noop registered (default)
$ dmesg | grep -i zswap
[    0.724855] zswap: loaded using pool lzo/zbud
$ cat /sys/kernel/mm/transparent_hugepage/enabled
always [madvise] never
$ sysctl vm.swappiness
vm.swappiness = 25
$ sysctl vm.vfs_cache_pressure
vm.vfs_cache_pressure = 1000

Обновить

Увеличение vm.min_free_kbytes на шаге № 3 может быть полезным. Попробуйте указать значение 131072 (128 МБ). Последний вывод заключается в том, что Linux на рабочем столе не очень хорошо работает в ситуациях с нехваткой памяти. Некоторые предлагали разместить Chrome / Chromium в cgroup , но это выходит за рамки этого ответа.

Я не уверен, почему этот ответ не был предложен: killall -9 kswapd0

Я столкнулся с этой проблемой, когда процесс kswapd0 выполнялся как пользователь без полномочий root, у которого давно не заходил. Я убил этот процесс, и проблема не вернулась.

Нет, это не устраняет корневую проблему (как вообще удалось достичь 100%-го результата), но позволяет быстро восстановить использование системы.

Ни один из перечисленных здесь ответов мне не помог. Я попробовал более простой подход «IT Crowd», отключив своп, а затем снова включив его.

# swapoff -a, затем # swapon -a.

Я бы не рекомендовал это делать, если на сервере катастрофически не хватало ОЗУ, но в моем случае ОЗУ было много, но по какой-то причине своп кипел. Своп очищен, загрузка процессора вернулась к норме.

По собственному опыту, kswapd#указывает, что память используется полностью, и подкачка была активирована автоматически для выполнения своей функции резервного копирования памяти. Убить процесс — не очень хорошее решение, потому что он становится временным, а не будущим. Я рекомендую увеличить память на машине, чтобы сохранить производительность в процессах. В моем случае это было связано с наличием нескольких виртуальных машин на одном сервере. Две ВМ потребляют много ресурсов на свои процессы. С уважением