Большое потребление SWAP в работе KVM?

Question

[akordik]

Установлен Proxmox Virtual Environment 5.2-1, ФС ZFS
(Linux 4.15.17-1-pve #1 SMP PVE 4.15.17-9 (Wed, 9 May 2018 13:31:43 +0200))
ОЗУ установлено 62гб в работе примерно 50%-60%
Обратил внимание на большое потребление swap.
В диспетчере задач увидел большое потребление SWAP запущенными процессами вм. KVM (забрал 2гб)

Почему KVM при свободном ОЗУ так сильно использует SWAP?
Насколько это нормально и что будет при увеличении кол-ва машин (боюсь увидеть 100%)?
Если это не нормально, как можно это пофиксить ?

Comments

[Sanes]

Тоже самое при большом аптайме.

[Drno]

Отключите свап. И посмотрите. Память скорее всего жрет zfs. Она так работает

[akordik]

Нашел на сайте proxmox
https://pve.proxmox.com/wiki/ZFS_on_Linux#zfs_swap

Answer 1

[АртемЪ]

Почему KVM при свободном ОЗУ так сильно использует SWAP?

Для управления памятью. Какой тогда смысл в SWAP если его не использовать?

Насколько это нормально и что будет при увеличении кол-ва машин (боюсь увидеть 100%)?

Использование SWAP абсолютно нормально.
Ненормально это когда объема ОЗУ не хватает и приходится использовать SWAP вместо ОЗУ.

Answer 2

[shurshur]

Свободная память - это free. В avail показывается "потенциально доступная" память, если система сбросит все дисковые кэши.

Система превентивно сбрасывает часть данных в swap для того, чтобы был запас свободной памяти. Это поведение зависит от переменной vm.swappiness, задающей процент занятой памяти, при превышении которого система начинает перенос данных в swap. Я бы посоветовал проверить её значение, возможно, там стандартные 60%, что на системе с 64 Гбайтами будет означать, что swap начинает использоваться после 38.4 занятой памяти. Собственно, в used на скриншоте почти столько и есть.

Посмотреть текущее значение можно так:

sysctl vm.swappiness

Если это как-то мешает, можно увеличить, например, до 75%, что будет давать порог в 48 Гб. Но под кэш останется не больше 16 Гб, при активном дисковом обмене уменьшение может оказаться заметным, особенно на HDD.

Comments

[edo1h]

Это поведение зависит от переменной vm.swappiness, задающей процент занятой памяти, при превышении которого система начинает перенос данных в swap

https://habr.com/ru/post/344836/#comment_10569644

[shurshur]

edo1h, я понимаю, что это неточно, как и то, что напрямую складывать размеры дискового кэша и памяти приложений для определения занятого объёма тоже нельзя.

Answer 3

[Пума Тайланд]

Уменьшите свап размер
Откажитесь от зфс
Станет сильно лучше

Answer 4

[Лев Забудкин]

активируйте zswap, 27 гигов свопа это не нормально.
Когда будете читать про zswap. там и настроете.

Comments

[shurshur]

Свопа у него 8 Гб, а 27 Гб - это available, 24 Гб в физической памяти и 3 Гб в свопе.

Answer 5

[edo1h]

«Потребление swap» нужно в первую очередь смотреть не в гигабайтах, а в операциях в секунду, если у вас нет никакого мониторинга, то можно с помощью iostat -mxzp 10
Если у вас много IOPS на разделе со свопом — тогда и нужно что-то предпринимать, если же нет — радуйтесь, у вас там осели неиспользуемые данные, можно сказать бесплатно память добавилась (хотя для заметного эффекта размер свопа должен быть одного порядка с размером памяти, конечно).

«Много IOPS» — это сколько? Можно считать в процентах от производительности диска, условно HDD умеет 100 IOPS, так что менее 10 обращений к свопу в секунду (менее 10% от потенциала диска) не окажут существенного влияния на производительность системы. Для SSD цифры будут куда выше, там и тысячи IOPS на своп могут быть нормальными (но для десктопных SSD надо помнить про ресурс дисков/забивание SLC кэша).

что будет при увеличении кол-ва машин (боюсь увидеть 100%)?

Само по себе это не не страшно. Но вот если приложениям (виртуальным машинам в вашем случае) не хватит общей памяти (физическая+своп), то у ядра не остаётся выбора кроме OOM killer.

Повторюсь, особого смысла в свопе, размером на порядок меньшим, чем объём физической памяти, я не вижу.
Обычно я настраиваю размером или с RAM (там, где он нужен, как в вашем случае), или вообще без swap (если на хосте, скажем, только postgresql или elsaticsearch).

Резюмируя:
- если у вас всё нормально с производительностью, IOPS, связанных со свопом мало — то ничего не делать, разве что рассмотреть возможность увеличения раздела со свопом «на вырост»;
- если дисковая система тормозит, то увеличивать объём оперативной памяти (или умерять аппетиты приложений).