Оптимизация оперативной памяти в Proxmox

Всем привет!!!

В этом материале я поделюсь с вами информацией как оптимизировать ОЗУ в Proxmox ну и заодно эта инструкция будет служить мне шпаргалкой на будущее.

У меня дома имеется сервер виртуализации на базе гипервизора Proxmox VE. Сервер построен на энергоэффективном процессоре и 32Г оперативной памяти. Казалось бы ОЗУ предостаточно, так думал и я. Но оказалось, что я могу запустить всего 4 виртуальные машины и эта самая ОЗУ закончится. Причем мои подсчеты показывали, что я не выделял такое количество памяти для моих виртуальных машин.

В связи с этим я озадачился оптимизацией ОЗУ для Proxmox. И результаты меня приятно удивили.

Вот например на скринах видно результат моей оптимизации ОЗУ для 4-х виртуальных машин. Как видите результат на лицо. Удалось сэкономить около 7-8 ГБ оперативной памяти. Более того, если до оптимизации я не мог запускать более 4-х виртуальных машин, то после я смог запустить 8 без ущерба для сервера и это не предел.

Оптимизация ZFS кеш

Все знают, что ZFS очень любит оперативную память, но зачем и для чего задумываются единицы. Я кстати только сейчас, когда делал статью, задумался об этом. А ведь это очень важный аспект в ОС с файловой системой ZFS.

ARC (Adaptive Replacement Cache) в ZFS – это эффективный механизм кеширования, который использует сложные алгоритмы для минимизации обращений к диску на чтение. Чем лучше работает ARC и чем больше данных попадает в кеш, тем сложнее избавиться от них. Это приводит к тому, что ZFS обычно использует всю доступную память под ARC. Хотя это может быть полезно, стоит помнить, что память – дорогой ресурс, особенно если используются быстрые SSD или NVMe накопители.

В результате можно ограничить использование ZFS кеша, что бы для виртуальных машин было больше ОЗУ, но если у вас жесткие диски, а не SSD, то приготовитесь к снижению отклика производительности в виртуальных машинах при обращении к дискам.

Некоторые выбирают btrfs, что бы не испытывать проблем с кешем ZFS, но как по мне лучше отключить кеш вовсе, чем использовать btrfs, которая на данный момент для Proxmox носит тестовый релиз, т.е. разработчики не встроили ее должным образом и еще изучают ее поведение.

Для ограничения ZFS кеша создайте такой файл /etc/modprobe.d/zfs.conf

nano /etc/modprobe.d/zfs.conf

Впишите в него следующие параметры

options zfs zfs_arc_min=1073741824
options zfs zfs_arc_max=2147483648

Я ограничил кеш от 1ГБ до 2ГБ. Вы же можете сделать собственные настройки по такой формуле N*1048576*1024. Это связано с тем, что размер кеша указывается в байтах.

Теперь нужно обновить образ загрузчика так:

update-initramfs -u

При использовании UEFI выполните еще такую команду:

pve-efiboot-tool refresh

Изменения вступят в силу после перезагрузки сервера Proxmox

Для отслеживания использования ARC кеша используйте команду arcstat

Настройка KSM

КSM (Kernel Same-page Merging) – это функция ядра Linux, которая позволяет объединять одинаковые страницы памяти различных процессов для уменьшения потребления ресурсов. Этот процесс можно сравнить с оптимизацией использования оперативной памяти путем удаления дублирующихся данных. При использовании множества однотипных виртуальных машин KSM может значительно уменьшить объем занимаемой памяти.

В proxmox служба KSM включена по умолчанию, как и ее настройки. С настройками по умолчанию KSM начинает работать когда на Proxmox остается 20% свободной памяти. Вообще там много настроек, но я буду менять только эту одну.

Некоторым может показаться странным, что разработчики выставили такой маленький процент, но у KSM есть другая сторона медали. Дело в том, что процесс дедупликация ОЗУ занимает очень много процессорного времени. По-простому говоря он будет нагружать процессор иногда даже сильнее чем виртуальная машина. Поэтому увеличивать процент, при котором начнет работать KSM слишком много не стоит.

Я решил, что для моих не требовательных виртуальных машин, энергоэффективного процессора и размера ОЗУ лучшим вариантом для начала работы KSM будет 30-40 %. Поэтому я установил это значение в 35%. В результате после занятия 20ГБ ОЗУ начнет работать KSM стремясь не дать серверу израсходовать больше этого объема за счет дедупликации оперативной памяти.

Для этого нужно отредактировать файл /etc/ksmtuned.conf

nano /etc/ksmtuned.conf

Раскомментировать строку и заменить на свое значение ее параметр:

KSM_THRES_COEF=20

В этом файле есть и другие интересные параметры, более подробно можно почитать в исходниках, ссылки на которые я оставлю в конце статьи.

Теперь для применения изменений сделайте рестарт службе KSM (сервер перегружать не нужно):

systemctl restart ksmtuned

Для отслеживания работы KSM можно воспользоваться командой cat /sys/kernel/mm/ksm/pages_sharing

Ballooning (Полет на воздушном шаре)

Увеличение объема памяти в KVM позволяет гостевой операционной системе динамически изменять использование памяти путем освобождения неиспользуемых ресурсов во время работы. Это помогает снизить влияние, которое гость может оказывать на использование памяти хоста, возвращая неиспользованную память обратно хосту.

Proxmox VE может предоставлять дополнительную память для загруженной виртуальной машины. Сама виртуальная машина принимает решение о том, какие процессы или страницы кэша можно заменить, чтобы освободить память для расширенной виртуальной машины. Виртуальная машина (будь то Windows или Linux) лучше всего знают, какие области памяти можно использовать без ущерба для ее производительности.

Необходимым требованием является установка гостевых дополнений:

Для Window:

1. Загрузить последнею стабильную версию драйвера в виде ISO образа.
2. Подключите образ как CD-ROM
3. Установите virtio-win-gt-x64 и затем virtio-win-guest-tools
4. Перезагрузите Windows

Для Linux:

• Debian\Ubuntu: apt-get install qemu-guest-agent затем systemctl start qemu-guest-agent
• Если после перезагрузки не запускается, то выполните эту команду: systemctl enable qemu-guest-agent

Теперь когда ваши виртуальные машины готовы для динамического расширения оперативной памяти их нужно настроить. Для этого остановите виртуальную машину и отредактируйте настройки ее ОЗУ. Установите флажок раздуваемой памяти и назначьте минимальное и максимальное значение. После чего включите виртуальную машину и наблюдайте.

У каждой виртуальной машины эти параметры могут быть уникальными. В примере выше моя тестовая Windows 11

Итог

В результате после всех проделанных изменений и оптимизаций работы оперативной памяти в Proxmox я смог запустить разом все те виртуальные машины, которые до этих изменений не мог даже подумать запускать одновременно. Я молчу сколько я еще смогу запустить виртуальных машин благодаря всего 5-10 минут потраченных на оптимизацию ОЗУ в Proxmox.

На картинке ниже видно, что объем занимаемой ОЗУ сейчас 64,35% и равен почти 20ГБ при запущенных 8 виртуальных машинах, в то время как KSM (дедупликация памяти) равен 6,46ГБ. Получается, что практически нет выделения памяти под кеш ZFS, так еще и виртуальные машины стали правильно работать с ОЗУ, а KSM дополнительно экономит порядочно гигабайт.

Оказывается 32ГБ оперативной памяти для Proxmox вполне достаточно в моих задачах и не стоит даже думать об апгрейде ОЗУ.

Материалы, которыми я пользовался:

• https://interface31.ru/tech_it/2022/07/nastraivaem-ispolzovanie-ram-pri-rabote-s-zfs-v-proxmox-ve.html
• https://vlytkin.ru/docs/poleznye-komandy-dlya-proxmox-optimizaciya-zfs/
• https://pve.proxmox.com/wiki/Dynamic_Memory_Management
• https://bafista.ru/domashnij-server-virtualizaczii-na-osnove-proxmox-ve/
• https://www.dlford.io/memory-tuning-proxmox-zfs/

Теперь вы знаете как оптимизировать оперативную памяти в Proxmox