Возможность Memory overcommit в Xen появилась начиная с версии Xen 3.3 и позволяет в разы превышать фактический объем оперативной памяти, что предоставляет хостеру возможность (overselling-а) продавать больше ресурсов чем у него есть в наличии.
Например, если ваша машина имеет 4 Гб оперативной памяти, и вы хотите запускать столько 1GB доменов, сколько это возможно, то до версии Xen 3.3 вы могли запустить не более трех. С новой "фичей" "Memory overcommit", в некоторых средах на базе Xen 3.3 и выше, вы сможете запустить шесть, десять или даже более доменов.
При соответствующей настройке Xen доменов, оперативная память отнимается у одного домена и передаётся другому, который использует механизм Xen "ballooning" (надувательство). Для примера, домен находящийся в состоянии ожидания (idle) и не требующий в текущий момент выделенной ему памяти может стать донором оперативной памяти для другого домена.
Вся хитрость Xen overselling-а, или можно сказать сложность, заключается в том, как правильно определить объем памяти, которую можно отнять у одного домена в пользу другого и при этом не вызвать проблем в работе "донора", а также в том, как вернуть РАМу донору если он начнёт в ней нуждаться.
В качестве балансирующего инструмента следящего за потребностью доменов в оперативной памяти в Xen используется "self-ballooning". Для реализации "Memory overcommit" все домены должны быть правильно сконфигурированы на использование swap (файл подкачки), а также все домены работающие в режиме аппаратной виртуализации (HVM) должны иметь "balloon" драйвер и рабочий инструмент "Xenstore tools".
Скрипты и более подробную информацию README можно найти в исходниках xen.hg/tools/xenballoond или в MemoryOvercommit-XenSummit2008.pdf.
Как определить использование balloon механизма (overselling-а)?
Иногда встречаются хостинг провайдеры, которые красноречиво заявляют "PS. Используемая нами технология виртуализации XEN исключает возможность оверселлинга!", что уже немного настораживает имхо мы то знаем, что по сути XEN НЕисключает возможность оверселлинга (разумеется начиная с Xen 3.3)!
Возможно это правда и некоторые VPS хостинги не используют balloon механизм для "оверселлинга", но нам одного заявления должно быть мало и мы должны как-то самостоятельно удостоверится в том, что получили VPS сервер с реально выделенными ресурсами.
Определить наличие balloon драйвера в системе особого труда не составит, для этого достаточно выполнить "cat /proc/xen/balloon" и если мы получим положительный результат, то значит имеем в системе наличие ballooning механизма:
# cat /proc/xen/balloon Current allocation: 524288 kB Requested target: 524288 kB Minimum target: 173056 kB Maximum target: 532480 kB Low-mem balloon: 8192 kB High-mem balloon: 0 kB Driver pages: 224 kB
Возможно также наличие демонов типа xenballoond. Объяснение вывода "/proc/xen/balloon":
- Current allocation: сколько РАМы выделено в текущий момент;
- Requested target: сколько РАМы было запрошено текущим доменом (ОС);
- Minimum target: минимальное количество РАМы, которое нужно зарезервировать для текущего домена;
- Maximum target: максимальное количество РАМы, которое можно зарезервировать для текущего домена;
- Low-mem balloon: сколько минимум может быть взято РАМы (ballooning - раздуто) с текущего домена за один раз/зпрос/подход;
- High-mem balloon: сколько максимум может быть взято РАМы с текущего домена за один раз/зпрос/подход;
- Driver pages: страницы памяти обрабатываемые драйвером? нет? предложите свой вариант?
Объяснение вывода "/proc/xen/balloon" как таковое в документации не обнаружено, а поэтому по некоторым пунктам я могу и ошибаться.
Механизм Xen "ballooning", можно перевести как "надувание" и если провайдер Вам пообещал реально выделенные ресурсы, без "оверселинга", то и надувать (ballooning) он Вас не должен! Ну, а если в системе обнаружился /proc/xen/balloon, то значит всё таки Вас надули или только собираются!:)
Динамическое распределение ресурсов в Xen - это возможно.
И в завершении немного про оверселинг в VMware, признаки которого можно проверить командой "vmware-toolbox-cmd stat balloon" входящей в состав vmware-tools и если результатом будет "0 MB", то значит вся выделенная Вам РАМа пока Ваша:
# vmware-toolbox-cmd stat balloon 0 MB # vmware-toolbox-cmd stat swap 0 MB
Ссылки по теме:
- Xen 3.3 Feature : Memory Overcommit – blog.xen.org
- Chapter 37. Troubleshooting the Xen para-virtualized drivers - Red Hat Customer Portal
