[УРОК] FABC: Почему Proxmox VE использует всю мою оперативную память и почему я не могу видеть реальное использование оперативной памяти виртуальных машин на панели управления?
[УРОК] FABC: Почему Proxmox VE использует всю мою оперативную память и почему я не могу видеть реальное использование оперативной памяти виртуальных машин на панели управления?, Proxmox Виртуальная Среда
Эта статья посвящена вопросу, на который часто отвечают участники сообщества. Она вдохновлена отличными постами UdoBs ( https://forum.proxmox.com/search/7994094/?q=FabU&c[title_only]=1&c[users]=UdoB ) и направлена на предоставление подробного объяснения часто задаваемому вопросу, чтобы его можно было ссылаться на него в будущих обсуждениях. Она будет обновляться по мере необходимости, любые отзывы/предложения приветствуются.
В моей панели мониторинга показано, что большая часть моей оперативной памяти используется, хотя у моих ВМ и контейнеров LXC выделена лишь небольшая ее часть. Это ошибка утечки памяти? Вероятнее всего, нет.
Прежде всего, вам нужно знать, что ProxmoxVE основан на Debian Linux с ядром Ubuntu. Ядра Linux отлично справляются с использованием неиспользуемой памяти для кэша диска. Это хорошо, поскольку это ускоряет работу, но часто беспокоит пользователей, перешедших с другой операционной системы или гипервизора (хотя они тоже делают что-то подобное, их мониторинг просто сообщает об этом по-другому). Фактически, было бы более тревожно, если бы у вас было, скажем, 128 ГБ оперативной памяти, но использовалось бы только 32 ГБ. Неиспользуемая оперативная память в основном пропадает.
Я использовал `free -m`, чтобы определить размер моего кэша, но в панели мониторинга все равно есть используемая оперативная память, которая не используется ни системой кэша, ни моими ВМ и контейнерами LXC.
Вы используете ZFS? ZFS использует часть памяти хоста для своего адаптивного кэша замены (ARC). Его использование не отображается в выводе `free -m`. Обычно ZFS использует около 50% системной оперативной памяти, но вы можете перенастроить его в `/etc/modprobe.d/zfs.conf`.
Начиная с ProxmoxVE 8.1, этот файл создается во время установки системы и ограничивает использование ARC до 10% установленной физической памяти или максимум 16 ГБ. Ознакомьтесь с https://pve.proxmox.com/wiki/ZFS_on_Linux#sysadmin_zfs_limit_memory_usage, чтобы узнать, как изменить этот лимит или создать файл, если он отсутствует в вашей системе.
Я проверил использование оперативной памяти внутри ВМ, и она на самом деле использует гораздо меньше оперативной памяти, чем я выделил в настройках ВМ. Не должна ли панель мониторинга ProxmoxVE отражать реальные значения? Вопрос в том, какое значение "реальное"? Внутри ВМ используется только часть выделенной ей оперативной памяти, но ВМ в целом все равно использует всю выделенную ей оперативную память, поэтому ее нельзя использовать другим ВМ/контейнерам и т.д.
Чтобы на самом деле настроить использование оперативной памяти ваших ВМ (то есть настроить параметры памяти ваших ВМ так, чтобы у них была именно та оперативная память, которая им нужна, не больше, не меньше), вам потребуется инструмент мониторинга, работающий внутри вашей ВМ.
Теперь для выбора правильного программного обеспечения для этого, вам понадобится отдельный пост. Я не знаю вашего уровня подготовки и сценариев использования. Существуют также разные типы программного обеспечения для мониторинга в зависимости от того, чего вы на самом деле хотите достичь. Для получения дополнительной информации о различных типах прочтите эту статью в блоге от Kristian Koehntopp: https://blog.koehntopp.info/2017/08/09/monitoring-the-data-you-have-and-the-data-you-want.html
И если вы понимаете немецкий (или используете хороший машинный переводчик), то Marianne Spiller написала отличную статью об основах мониторинга и анализа требований, проектирования и реализации системы мониторинга: https://www.unixe.de/monitoring-basics/
В нашем контексте мы говорим о программном обеспечении, которое Koehntopp называет типом один мониторинговой системы. Она используется для наблюдения за системными параметрами и предупреждения, если что-то пошло не так (например, полный диск), но также может использоваться для наблюдения за использованием оперативной памяти и нагрузкой ЦП/системы. Популярные примеры с открытым исходным кодом для такого типа мониторингового программного обеспечения — Zabbix, Prometheus, Icinga2, Nagios или Checkmk. Но также есть коммерческие предложения (например, PRTG) и менее используемые инструменты с открытым исходным кодом.
Выберите один из них (возможно, после экспериментов с каждым из них в небольшом контейнере LXC или ВМ просто для практики), наблюдайте за использованием оперативной памяти ваших контейнеров и ВМ и настраивайте параметры ВМ в соответствии с вашими потребностями.
Другие гипервизоры имеют опции, позволяющие динамически выделять неиспользуемую оперативной памяти одного ВМ другим ВМ. Как я могу этого добиться с помощью ProxmoxVE?
В теории есть два варианта динамического управления памятью:
* Дeduplication памяти между различными ВМ Linux с использованием Kernel Samepage Merging (KSM). Для этого необходимо много ВМ с похожими работающими приложениями и ядрами, чтобы это работало. Ознакомьтесь с https://pve.proxmox.com/wiki/Kernel_Samepage_Merging_(KSM) для получения дополнительной информации. * ВМ с драйвером ballooning. ВМ могут сбрасывать неиспользуемую память во время работы (ballooning памяти). Этот драйвер уже встроен в современные ядра Linux, а для Windows вам сначала нужно установить драйвер.
Но не ожидайте слишком многого: сначала оперативная память должна быть полностью использована, прежде чем будет предпринята попытка ballooning, и вы никогда не сможете иметь слишком много оперативной памяти.
У меня все еще есть несколько нерешенных вопросов. Не стесняйтесь задавать их здесь или в исходной ветке, где был размещен этот пост.
Если в статье что-то не так / у меня есть предложение что-то добавить, я буду рад любым отзывам, просто отправьте мне личное сообщение или ответьте на эту ветку.
Версия 0.1: Первый пост
Версия 0.2: Исправлены некоторые опечатки, добавлена информация о драйвере ballooning, спасибо @Impact за предложения
Версия 0.3: Добавлена ссылка на статью @chrcoluk об кэше ARC ZFS по сравнению с кэшем страницы Linux.
Возможно, я тут немного придираюсь, но мне кажется, что гостевой агент — это отдельная вещь от драйвера/сервиса "ballooning", и один можно использовать/установить без другого.
Память не резервируется при запуске ВМ (пока вы не определите статическую память huguge в vm.conf напрямую). Таким образом, её можно динамически выделить для другой ВМ. Если ВМ резервирует страницу памяти, она зарезервирована. Обратите внимание, что Windows при загрузке выделяет все страницы памяти нулями (то есть резервирует их), а в Linux ВМ выделяется только необходимая память при загрузке. Если гостевая ОС ВМ освобождает страницу памяти, драйвер Balloon может уведомить хост Proxmox о том, что страница памяти свободна (что-то вроде discard для диска). https://lwn.net/Articles/808807/ (поэтому крайне важно не отключать опцию Balloon, даже если вы не используете функцию min_size для Ballooning). KSM – это просто дедупликация памяти (включая страницы с нулями из Windows) на уровне хоста, когда использование хоста достигает 80%. Ballooning может динамически уменьшить объем памяти гостевой ВМ, определенный как "min memory", когда использование хоста достигает 80%. Агент гостя вообще не используется для управления памятью. Драйвер Balloon также используется для получения статистики памяти гостя Proxmox. (если отключить драйвер Balloon, вы увидите только использование памяти всего процесса Qemu на уровне хоста).
Если только не произойдет удивительное событие, когда настроен "PCI passthrough", то он должен быть "активным" с самого начала из-за вероятности использования DMA. Отказ от ответственности: насколько я знаю = никогда там не был.
Зависит, цитирую страницу вики по ссылке: https://pve.proxmox.com/wiki/Dynamic_Memory_Management. Я не стал включать это в объяснение, потому что хочу, чтобы люди сначала почитали документацию. FABC больше как точка отсчёта, я не хочу снова переписывать всю документацию.