Задний план
Мы используем несколько KVM-серверов на Ubuntu 16.04 и начали тестирование обновления до 20.04.
Мы обнаружили, что, хотя мы никогда не видели использования подкачки на наших серверах 16.04, через пару дней сервер 20.04 покажет использование подкачки в несколько сотен МБ.
Это не большая проблема, так как vmstat показывает очень небольшую активность подкачки, а графики munin подтверждают, что ввод/вывод подкачки незначителен, но мы все же хотим понять поведение.
До сих пор мы использовали Nagios для мониторинга использования подкачки и оповещения, если таковая найдена.
Система, которая была обновлена с 16.04 по 20.04, работает с пятью виртуальными машинами с небольшой нагрузкой.
Хост-система использует память около 29 ГБ из примерно 200 ГБ общей памяти. Никаких пиков или чего-либо, что приводит к тому, что использование памяти становится таким высоким. Использование памяти виртуальной машиной ограничено, и на самом KVM-сервере не запущены другие требующие памяти процессы.
root@kvm-xx:~# бесплатно -m
общее количество использованных бесплатных общих баффов/доступных кешей
Мем: 193336 29495 768 5 163072 162404
Обмен: 6675 240 6435
Вверху, пример обмена процессами:
PID VIRT RES SHR S %MEM COMMAND SWAP
6447 18,2 г 15,8 г 22908 S 8,4 qemu-система-x86 239352
6160 2661052 1,9g 21880 S 1,0 qemu-система-x86 90788
6315 2129436 644388 21856 S 0,3 qemu-система-x86 29724
6391 10,4 г 7,9 г 22832 S 4,2 qemu-система-x86 24028
6197 6505584 3,0 г 23008 S 1,6 qemu-система-x86 10972
5686 9908 2944 2720 S 0,0 крон 60
5805 24404 14440 4388 S 0,0 мунин-узел 4
Типичный вывод vmstat, показывающий отсутствие изменений в свопинге.
root@kvm-xx:~# vmstat 2 10
procs -----------память---------- ---своп-- -----io---- -система-- ------процессор -----
r b swpd бесплатный кэш баффов si so bi bo in cs us sy id wa st
0 0 407620 869916 214784 165081536 0 0 270 12 5 2 0 2 98 0 0
2 0 407620 869900 214784 165081536 0 0 0 28 8533 24140 0 2 98 0 0
1 0 407620 869836 214784 165081536 0 0 0 28 8642 24682 0 2 98 0 0
Эта система работала в течение года с нулевым свопом 16.04 с теми же виртуальными машинами и нагрузкой.
Что было опробовано и испытано
После обновления обнаружилось, что numad не был установлен, а виртуальные машины не были привязаны к vcpu на том же физическом процессоре. Значение использования памяти на узлах numa. Установил numad и проверил пиннинг. Я считаю, что использование подкачки было выше перед это изменение, но не могу сказать наверняка.
Ожидалось, что это поведение будет связано с ядром, поэтому было обновлено с ядра 5.4 до ядра HWE 5.11. Такое же поведение как на 5.4, так и на 5.11.
Попытался отключить KSM (слияние одной и той же страницы ядра), так как он нам не нужен, и исключить его как возможный источник использования подкачки.
Попытался полностью отключить своп, чтобы увидеть, действительно ли не хватает памяти, когда на вечеринку придет OOM-killer. Этого не произошло, поэтому мне кажется, что своп не требуется, но по какой-то причине все еще используется.
Идеи и мысли
Я полагаю, что по какой-то причине ядро решает подкачать неактивные страницы для подкачки, даже если swappiness = 0. Вероятно, это поведение изменилось с новыми ядрами, которые поставляются с 20.04.
В идеале мы хотели бы, чтобы ядро выполняло подкачку только в крайнем случае, как раньше, и использовало мониторинг использования подкачки, чтобы обнаруживать использование подкачки и поднимать тревогу Nagios.
Я читал несколько тем на похожие темы, но нашел противоречивую информацию о том, что может быть объяснением.
Чего я действительно хочу избежать, так это ситуации, когда мы обновим некоторые из наших наиболее загруженных серверов 16.04 до 20.04 и увидим, как эта проблема перерастет в реальную проблему в производстве.
Я знаю о swapoff/swapon при ручном перемещении памяти из подкачки, но вопрос в том, почему она вообще подкачивает.
Если у кого-то есть понимание этого, будем очень признательны.
Спасибо!
