Назад | Перейти на главную страницу

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

В большинстве случаев, когда моему компьютеру требуется подкачка, я вижу резкий скачок загрузки ЦП (kswapd0 постоянно использует 99% -100% ЦП). В соответствии с top, время проводится в sy (система / ядро) нет wa (IO, подождите).

Я использую Linux 4.0.4-2-ARCH на C720 с 2 ГБ ОЗУ и 6 ГБ подкачки на SSD.

Кажется, у меня возникла эта проблема с включенной функцией сброса страниц (TRIM) или без нее.

Есть ли какие-то настройки, которые я должен проверить или настроить, чтобы узнать, могу ли я это исправить?

Есть ли способ устранить проблему? Что-то вроде strace для потоков ядра?

Запуск с настройками Arch Linux по умолчанию:

/proc/sys/vm/swappiness знак равно 60
/proc/sys/vm/vfs_cache_pressure знак равно 100
/sys/kernel/mm/transparent_hugepage/enabled знак равно [always] madvise never

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

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

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

У меня C720 с ядром Linux 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 и добавьте следующее:
  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, но это выходит за рамки этого ответа.

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

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

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

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

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

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

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

3) Что cat /sys/kernel/mm/transparent_hugepage/enabled?

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

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

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

Если у вас есть служба, работающая внутри докера, например, puppeteer (chrome headless api). Внутри вашего файла dockerfile добавьте тупой.

Если запущен Docker> = 1.13.0, используйте docker run --init arg, чтобы получить зомби-процессы.

docker run container --init

Если вы используете <= 1.13.0 в докере, используйте dumb-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", "--"]

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

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

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