Оперативная память (RAM) — это один из тех ресурсов домашней лаборатории, который может исчезнуть ОЧЕНЬ быстро, особенно если не уделять внимания его распределению. В современном мире RAM является дефицитным товаром, покупка которого обходится недешево. Существует несколько способов расширить доступную оперативную память в Proxmox. Некоторые из них позволяют реально снизить потребление памяти. Ниже описаны семь способов оптимизации использования RAM на серверах Proxmox.
1. Замена небольших виртуальных машин Proxmox контейнерами LXC
Один из способов экономии памяти в среде Proxmox довольно прост. Рекомендуется не создавать полноценную виртуальную машину, если для этого нет конкретной причины. Вместо этого следует использовать контейнеры LXC. Это может показаться простым и незначительным, но это изменение в подходе к администрированию.
При сравнении LXC с полноценной ВМ видно, что виртуальной машине требуются собственные ОС и ядро. При создании 5 виртуальных машин Ubuntu каждая из них будет иметь отдельную операционную систему Linux, со своим ядром, службами, кэшем памяти, процессами и т.д.
Ниже показан пример запуска контейнера Debian LXC на Raspberry Pi 5 с ограниченным объемом RAM (8 ГБ):
Контейнеры LXC работают иначе. Они используют ядро хоста Proxmox, предоставляя при этом изолированные пользовательские пространства. Это устраняет значительный объем дублирующихся накладных расходов. Для легких self-hosted сервисов это может дать огромную экономию памяти. Сервис, которому внутри ВМ могло потребоваться 4 ГБ, может нормально работать внутри контейнера LXC с 512 МБ RAM, в зависимости от типа сервиса.
При масштабировании этого подхода на 15 или 20 LXC вместо ВМ экономия становится весьма существенной. LXC отлично подходят для небольших веб-приложений, утилит, компонентов мониторинга, инструментов управления, служб DNS и других рабочих нагрузок Linux, которым не требуется аппаратная изоляция ВМ.
Что касается Docker, важно сделать замечание. Сам по себе Docker чрезвычайно легок. Неэффективность возникает, если выделять «толстую» ВМ всего для 1 или 2 контейнеров Docker. Вместо этого следует консолидировать их на как можно меньшем количестве хостов Docker, что снизит общий объем занимаемой памяти. Использование LXC вместо ВМ, где это возможно, и консолидация контейнеров Docker позволяют сэкономить значительный объем RAM.
2. Размещение swap Proxmox на быстром накопителе
В целом, к разделу подкачки (Swap) относятся предвзято. Вероятно, это связано с прошлым, когда при нехватке физической памяти машины начинали активно использовать swap на диске, и производительность резко падала. Однако с тех пор скорость накопителей значительно выросла.
Конечно, ни один NVMe SSD не сравнится по чистой скорости, задержкам и пропускной способности с памятью DDR5. Но это не значит, что его нельзя использовать с умом для помощи при нехватке памяти.
Был проведен эксперимент по тестированию выделенного диска для swap Proxmox. Для этого использовался старый диск Intel Optane. Optane имеет очень низкую задержку по сравнению с обычными NVMe дисками, во многом имитируя оперативную память. Он и был использован для пространства подкачки Proxmox.
Быстрые накопители, такие как диски Optane, делают процесс подкачки гораздо менее болезненным, чем во времена, когда swap размещался на шпиндельных дисках (HDD). При нехватке физической памяти swap может принять на себя часть нагрузки, не позволяя механизму Linux OOM killer (Out-Of-Memory killer) начать принудительное завершение процессов.
В Linux или Proxmox проверить состояние памяти и swap можно следующей командой:
|
1 |
free —h |
Также полезна команда:
|
1 |
swapon |
Подробности эксперимента и результаты тестирования доступны в полной статье: Руководство по настройке Proxmox Swap! Выделенный диск, Swappiness, Page Cluster.
3. Использование Proxmox memory ballooning
Чтобы извлечь максимум из физической памяти, установленной на хосте Proxmox, можно использовать функцию memory ballooning. Это один из самых полезных инструментов для эффективного использования ресурсов RAM.
Идея заключается в следующем. Виртуальная машина конфигурируется с максимальным объемом памяти, который она может получить. Функция позволяет Proxmox забирать часть этой памяти обратно, если гостевая ОС не использует ее активно. Например, если виртуальной машине выделено 16384 МБ памяти, можно установить минимальный объем памяти: 2048 и убедиться, что устройство ballooning включено.
В результате ВМ может задействовать до 16 ГБ памяти, когда это необходимо. Но Proxmox имеет возможность забрать часть этой выделенной памяти обратно, когда ВМ не использует ее активно для страниц памяти.
Например, можно настроить ВМ следующим образом:
|
1 2 3 |
Memory: 8192 MB Minimum memory: 2048 MB Ballooning Device: Enabled |
Здесь есть пара нюансов. Необходимо установить драйвер balloon. В Linux это обычно происходит автоматически, но гостевые системы Windows также могут использовать эту функцию с драйверами VirtIO. Также следует помнить, что лучше избегать использования memory ballooning для нагрузок, чувствительных к изъятию памяти.
Хорошим примером является ВМ с базой данных. Ей может быть выделено много памяти, которая необходима для кэширования данных. Поэтому ballooning следует рассматривать как инструмент, а не как опцию, которую нужно включать для КАЖДОЙ ВМ.
4. Правильный подбор объема памяти для ВМ Proxmox
Стоит признать, что при создании виртуальных машин в домашних лабораториях объем выделяемой памяти часто определяется «на глаз». Хотя такой подход нередко бывает успешным, он определенно может привести к серьезному избыточному выделению ресурсов (overprovisioning) или, что бывает гораздо реже, к их нехватке.
Рассмотрим, как это работает при использовании клонирования. Создается ВМ Ubuntu с 8 ГБ RAM, которая затем преобразуется в шаблон. При клонировании из этого шаблона клон получит те же 8 ГБ RAM, независимо от того, нужны они ему или нет.
По этой причине рекомендуется создавать шаблон с ОЧЕНЬ маленьким объемом памяти. Таким образом, нехватка памяти при запуске клона заставит обратить на это внимание и увеличить объем RAM, выделенной виртуальной машине. Для домашней лаборатории это лучше, чем непреднамеренное использование всей памяти клонами.
5. Проверка эффективности дедупликации памяти KSM
KSM — это служба Kernel Samepage Merging. Это функция управления памятью Linux, которая также присутствует в Proxmox. KSM ищет идентичные страницы памяти и позволяет ядру Linux объединять их. Это полезная функция, особенно в домашней лаборатории, где может работать несколько ВМ с одинаковой операционной системой, библиотеками и службами, поскольку они могут быть дедуплицированы.
О KSM легко забыть, так как управление им часто происходит в автоматическом режиме. Но эту службу полезно проверять время от времени, особенно если хост находится под давлением нехватки памяти.
Первый счетчик, который можно проверить:
|
1 |
cat /sys/kernel/mm/ksm/pages_sharing |
Это значение показывает, сколько страниц памяти в данный момент используют дедуплицированные страницы KSM. Если дубликатов много, это число будет довольно большим.
Также можно проверить, запущен ли сканер KSM, с помощью команды:
|
1 |
cat /sys/kernel/mm/ksm/run |
Результаты:
- Значение 1 – KSM запущен
- Значение 0 – KSM остановлен
Если отображается 0, это не обязательно означает проблему; возможно, давление на память недостаточно велико для включения службы. Proxmox использует службу ksmtuned для управления KSM. Следующим шагом стоит проверить ее статус:
|
1 |
systemctl status ksmtuned |
При проверке на одном из хостов Proxmox было обнаружено интересное наблюдение. Служба ksmtuned была включена и работала, но значения run и pages_sharing были равны 0.
Затем был проверен хост:
|
1 |
free —h |
Хост имел 128 ГБ физической памяти, из которых было доступно около 85 ГБ. Это означало, что у хоста не было веских причин для поиска дубликатов страниц на данный момент.
При желании можно выполнить быструю проверку KSM на хосте Proxmox с помощью этих простых команд:
|
1 2 3 4 |
systemctl status ksmtuned cat /sys/kernel/mm/ksm/run cat /sys/kernel/mm/ksm/pages_sharing free —h |
6. Очистка ненужных ресурсов Proxmox
В домашней лаборатории неизбежно накапливаются сервисы и ресурсы, которые, вероятно, больше никогда не понадобятся. Они могут оставаться в системе долгое время, так как находятся вне поля зрения. Рекомендуется еженедельно проверять запущенные сервисы и удалять все, что было оставлено по ошибке или не использовалось долгое время. Это включает шаблоны ВМ, шаблоны LXC, снимки состояний (snapshots), неиспользуемые ISO-образы и т.д.
Это позволяет избежать работы ВМ-зомби и контейнеров LXC в среде Proxmox. То же самое касается и контейнеров Docker, так как можно накопить множество контейнеров, даже не осознавая этого.
Дополнительная информация доступна в статье: 9 задач по очистке Proxmox, о которых вы, вероятно, забыли.
7. Предотвращение давления ZFS ARC на виртуальные машины
Последний пункт важен, если используется ZFS в кластере или на хосте Proxmox. ZFS очень требовательна к RAM. Она использует память для адаптивного кэша замены (Adaptive Replacement Cache), сокращенно ARC. ARC хранит наиболее часто используемые данные в памяти, чтобы ZFS не приходилось многократно извлекать их с более медленных накопителей.
Посмотреть статистику ARC в Proxmox можно с помощью команды:
|
1 |
arc_summary |
ZFS может освобождать память ARC, когда она требуется системе. Однако в системах с ограниченным объемом памяти при использовании ZFS (что весьма вероятно в домашней лаборатории) можно установить максимальный объем ARC.
Для этого необходимо отредактировать файл:
|
1 |
nano /etc/modprobe.d/zfs.conf |
Пример добавляемой строки:
|
1 |
options zfs zfs_arc_max=17179869184 |
Значение в файле указывается в байтах:
- 8 ГБ = 8589934592
- 16 ГБ = 17179869184
- 32 ГБ = 34359738368
- 64 ГБ = 68719476736
Затем необходимо обновить initramfs:
|
1 |
update—initramfs —u —k all |
Последний шаг — перезагрузка:
|
1 |
reboot |
Заключение
Не существует единственного волшебного способа получить больше физической RAM, чем установлено в системе. Однако описанные приемы позволяют ослабить давление на ресурсы памяти в лабораторной среде и улучшить производительность без физического расширения системной памяти. Если используются другие методы, не указанные здесь, рекомендуется поделиться ими с сообществом в комментариях.
Читайте про Свой умный дом локально:
🌐 Сайт
📱 Телеграм
📰 Дзен
