Resource Allocation

[FaRoR]

Прочел несколько русских и зарубежных статей настройки Resourse Allocation, в том числе http://frankdenneman.nl/2009/12/impact-of-memory-reservation/ , в которой рассзкаывается как рассчитываются значения Limit Share Reservation. Судя из того, что понял, выходит что расчет идет следующим образом: из заданного количества (буду приводить пример на RAM) оперативки, 2Гб вычитам заданное количество зарезервированных ресурсов, 1Гб, а остальное рассчитываем исходя из параметра Share. Допустим у меня 2 пула ресурсов (кластеру выделено 3Гб RAM), и один пул настроен как Medium другой Low. В медиуме у меня 2 ВМ, следовательно каждой выделится по 1Гб RAM. Если я зарезервирую за одной из ВМ 500Мб RAMкак тогда будет происходить раскидка ресурсов:

я так понял остальные 1500Мб поделятся пополам и будет раскидывание 1250Мб у одной ВМ и 750Мб у другой

либо 500Мб это всего лишь число, которое будет выдано полюбому, а раскидывание так и останется 1к1

И ще сразу вопрос, что если назначить Limit той ВМ, у которой стоит Reservation в 600Мб, будет ли использоваться второй машиной вся оставшаяся память (1400Мб) или она не затронется?

[mayonnaise]

Тимофеев Сергей wrote:

Получается, что при превышении лимита по памяти включается balooning, чтобы vmmemctl выбрал оптимальные страницы для переноса в VMkernel Swap ?

верно, но не для переноса в свап гипервизора, а для того что бы гость сам выбрал какие страницы отправить в свой внутренний свап.  Баллунинг - это инстурмент гипервизора повлиять на гостевой свапинг.

[Skyrod7]

Всегда считал, что балунинг- инструмент overcommitment'a, включается при битве ВМ за память.

И файл подкачки в гостевой ОС, мне кажется, в этом случае вобще не при делах. Гостевая ОС не знает ни о каком лимите по памяти, верит что у неё столько памяти, сколько указали при создании ВМ + сколько-то в её личном свопе.

При превышении Limit'a ВМ по-прежнему верит, что у неё всё то же количество физической памяти и еще свой своп. Вот только дальнейшая память будет выдаваться ей гипервизором из своп-файла ВМ.

Если и правда, Baloon Driver начинает работать на определение лучших страниц для помещения в своп-файл, то респект.

[mayonnaise]

Тимофеев Сергей wrote:

Всегда считал, что балунинг- инструмент overcommitment'a, включается при битве ВМ за память.

но в случае с лимитом оверкомтимента нет.

так же баллунинг используется и когда случается оверкомит. гипревизор забирает неиспользуемую память гостя.

Тимофеев Сергей wrote:

Гостевая ОС не знает ни о каком лимите по памяти, верит что у неё столько памяти, сколько указали при создании ВМ + сколько-то в её личном свопе.

При превышении Limit'a ВМ по-прежнему верит, что у неё всё то же количество физической памяти и еще свой своп. Вот только дальнейшая память будет выдаваться ей гипервизором из своп-файла ВМ.

гость не знает. а балун-драйвер знает. и с помощью него гипервизор забирает у гостя так называемую machine memory. а те страницы памяти гостя, кот ссылались на эту память (guest virtual), операционка помещает в свой свап. Так же не забываем, что параллельно работает TPS и compression. так что до внешнего свапа еще куча механизмов.

[Skyrod7]

В какой документации сказано, что при превышении лимита используется файл подкачки ОС, а не свап ВМ?

[mayonnaise]

Тимофеев Сергей wrote:

В какой документации сказано, что при превышении лимита используется файл подкачки ОС, а не свап ВМ?

вот пожалуйста

The memory balloon driver (vmmemctl) collaborates with the server to reclaim pages that are considered least valuable by the guest operating system. The driver uses a proprietary ballooning technique that provides predictable performance that closely matches the behavior of a native system under similar memory constraints. This technique increases or decreases memory pressure on the guest operating system, causing the guest to use its own native memory management algorithms. When memory is tight, the guest operating system determines which pages to reclaim and, if necessary, swaps them to its own virtual disk.

а именно баллунинг используется гипервизором для управления лимитом

забыл добавить название гайда - vSphere Resource Management Guide (стр. 29)

[Skyrod7]

mayonnaise wrote:

забыл добавить название гайда - vSphere Resource Management Guide (стр. 29)

Про лимиты там ни слова, но прочитал еще раз внимательнее http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=103311... , особенно "The VMkernel first tries to reclaim memory by inflating the Balloon Driver to let the guest memory manager decide what to page out.", похоже, что Ваша правда.

Вот тут - http://www.vmguru.com/articles/hypervisor/7-memory-behavior-when-vm-limits-are-set-revisited об этом говорят.

Был уверен, что используется .vswp

[mayonnaise]

Тимофеев Сергей wrote:

Был уверен, что используется .vswp

удалите гостевой файл подкачки и операционке больше некуда будет сбрасывать страницы памяти, кроме как в ram-кеш и внешний свап.

[michigun]

mayonnaise wrote:

Тимофеев Сергей wrote:

Был уверен, что используется .vswp

удалите гостевой файл подкачки и операционке больше некуда будет сбрасывать страницы памяти, кроме как в ram-кеш и внешний свап.

     Если вы по коридору
     Мчитесь на велосипеде,
     А навстречу вам из ванной
     Вышел папа погулять,
     Не сворачивайте в кухню,
     В кухне - твердый холодильник.
     Тормозите лучше в папу.
     Папа мягкий. Он простит.

сорри, не удержался

[Skyrod7]

А что скажет по этому поводу "тяжелая артиллерия"? ))

[michigun]

Тимофеев Сергей wrote:

А что скажет по этому поводу "тяжелая артиллерия"? ))

я со всем согласен, да и ссылку на свой пост на эту тему я уже приводил.

а последняя реплика была посвящена совету отключить своп гостей.

правда, надо признать, кое где в курсах такая рекомендация попадалась - про VDI.

правда, мне такая рекомендация кажется сомнителной.