@BloodVIRUS

Странное поведение процесса kswapd0?

Здравствуйте. Целый день веду сражение с сервером, и пока что он безоговорочно побеждает. Помощь у сил свыше (гугл, яндекс) не помогает..
В чем суть. В процессы затесался:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
7367 ded 20 0 2450276 2.299g 4 S 573.7 3.7 335:26.69 kswapd0

жрет оно половину мощностей сервера. Из 12 ядер на 100% загружено 5-6 ядер. Казалось бы, весь гугл говорит что у меня плохо с оперативной памятью.

KiB Mem : 65 876 508 total, 50 219 756 free, 8 858 456 used, 6 798 296 buff/cache

Но по факту 50гб просто пустое. Свопа до этого вообще не было. Ну хорошо, я создал своп файл на 128гб:

KiB Swap: 13421772+total, 13421772+free, 0 used. 56062892 avail Mem

сильно картину это не поменяло. Своп так и не используется (что логично, оперативной памяти еще 50гб свободно), но процесс kswapd0 от пользователя ded (? странный какой-то юзер) жрет половину сервера.
Может быть кто-то сталкивался с подобным? Все в сети сводится к единой практике: включайте своп, вам рамы не хватает.
Спасибо!
  • Вопрос задан
  • 249 просмотров
Пригласить эксперта
Ответы на вопрос 1
@zersh
kswapd - это просто демон, который занимается переносом и выгрузкой страниц памяти. не важно куда.
При наличии свопа, перенос в основном идёт с ним, но при его отсутствии - высвобождение какой-то памяти у какого то процесса, и передача её другому процессу - также осуществляется им.

Например, рассмотрим случай, когда у вас нулевая подкачка и в системе почти не хватает оперативной памяти. Ядро будет использовать память, например, из Firefox (оно может это сделать, потому что Firefox запускает исполняемый код, который был загружен с диска - при необходимости код может быть загружен с диска снова). Если Firefox затем потребуется снова получить доступ к этой оперативной памяти через N секунд, процессор генерирует "жесткий сбой", который заставляет Linux освободить часть оперативной памяти (например, взять часть оперативной памяти из другого процесса), загрузить недостающие данные с диска, а затем разрешить Firefox продолжить работу в обычном режиме. Это очень похоже на обычную замену, и kswapd0 делает это.

Т.Е. Сильная утилизация может действительно говорить о проблемах с планками памяти.
Обратите внимание на каких CPU постоянная нагрузка. выделены ли они одной numa ноде?
(если на сервере несколько cpu то память разделяется на каждый камень)
lscpu - покажет количество нод и какие номера vCPU к какой ноде относятся. таким образом можно будет предположить расположение проблемных планок.

И в любом случае, даже если один CPU cтоит проверить её. Например с помощью memtester
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы