keferoff
Contributor
Contributor

Ballooning, swaping влияние на производительность СХД

Доброго времени суток!

Концептуальный вопрос.

Имеется 5 серверов ESX 4.1 и одна СХД с очень низким колличеством ИОПС. Для снижения нагрузки на СХД, мы отказались от механизма балунинга памяти и перегрузки её в своп, задав лимиты доступной ОЗУ для всех ВМ на уровне директив Memory and Memory limit установив их в одно и тоже значение.

Правильно ли это или есть более изящьные способы?

Заранее спасибо!

0 Kudos
14 Replies
EGarbuzov
VMware Employee
VMware Employee

для всех ВМ на уровне директив Memory and Memory limit установив их в одно и тоже значение

Точно лимиты, вы не ошиблись? Потому что лимиты, равные номинальному значению памяти никак не должны влиять на механизмы memory overcommitment.

Для того, чтобы ни при каком условии не допускать выдавливание памяти в своп гипервизора (своп второго уровня .vswp) необходимо для всех машин дать Memory Reservation = количеству памяти в свойствах вм. Тогда каждой машине при запуске будет гарантированно выделяться сконфигурированный ей объём памяти. Но это сработает только если количество физической памяти на хосте перекрывает суммарные потребности запущенных вм + потребности самого ESX(i) и некоторый overhead.

При таких условиях ESX'у вроде бы не должно быть причин вообще использовать механизм ballooning.

Остаётся ещё своп внутри гостевой ОС, обращения к которому могут быть и без работы Ballooning. Если стоит задача запретить и этот уровень свопа (хорошо это или нет -- отдельный вопрос), то ИМХО это уже нужно делать средствами гостевых ОС.

0 Kudos
vMysh
Enthusiast
Enthusiast

использовать лимит, чтобы отказаться от баллунинга и дальше от нагрузки на диск, это не то, чтобы изящный способ, это изврат. Честно. Баллунинг нужен всегда и везде, это факт.

Это первое. Дальше - и самое интересное для Вас, наверное. Если ставить лимит, то это никак не отразиться на механизме баллунинга. Он будет работать, если память будет нужна, а ее не будет хватать.

А теперь по делу - вы действительно уверены, что ваша схд будет капитально лагать при работе балуна? Тесты делали? Посмотрите на показатели kavg davg и gavg в esxtop'e с балуном и без.

0 Kudos
keferoff
Contributor
Contributor

EGarbuzov всё именно так как вы описали, я допустил неточности в терминологии когда описывал свою инфраструктуру.

Dmitry wrote:

использовать лимит, чтобы отказаться от баллунинга и дальше от нагрузки на диск, это не то, чтобы изящный способ, это изврат. Честно. Баллунинг нужен всегда и везде, это факт.

Это первое. Дальше - и самое интересное для Вас, наверное. Если ставить лимит, то это никак не отразиться на механизме баллунинга. Он будет работать, если память будет нужна, а ее не будет хватать.

А теперь по делу - вы действительно уверены, что ваша схд будет капитально лагать при работе балуна? Тесты делали? Посмотрите на показатели kavg davg и gavg в esxtop'e с балуном и без.

на 100%, моя СХД это колхозный самосбор из 6SATA дисков образующих три массива RAID1. У меня бывает одна ВМ индексирует кеш своего приложения, так она уже генерирует под 200ИОПС\с, что в два раза перекрывает производительность одного массива моей СХД (САТА диск ~100ИОПС\с)

С балуном пробовал, несмотря на наличие свбодной памяти на серверах, балун всё равно работал сваливая данные в кеш на СХД. По идее такого быть не должно при достатке свободной ОЗУ на ESX, но это происходило и мы решили отказаться от балуна. Одним из аргументов было то что балун в отличие от свопа самой ОС незнает какие именно данные можно перегрузить в своп. Как мне кажется именно из-за этого ВМ в то время начали ощутимо медленее работать.

0 Kudos
Skyrod7
Expert
Expert

keferoff wrote:

Одним из аргументов было то что балун в отличие от свопа самой ОС незнает какие именно данные можно перегрузить в своп. Как мне кажется именно из-за этого ВМ в то время начали ощутимо медленее работать.

Ballon Driver как раз таки и вытесняет в гостевой своп наиболее подходящие для этого страницы.

Другое дело, почему работает балунинг при достаточности памяти?

0 Kudos
keferoff
Contributor
Contributor

..........Честно. Баллунинг нужен всегда и везде.........

Почему так считаете? Например, имеется сервер с 5ГБ ОЗУ и 5 ВМ на этом сервере с приложениями потребляющими по 2Гб ОЗУ при повседневном использовании.

Я считаю что в этом случае нужно отключить балун, т.к. гостевая ОС и само приложение лучше знаю какие данные перегрузить в своп. А если будет работать балун, то он вполне может перегрузить в своп активно используещееся данные, тем самым ещё более замедлив работу приложения.

0 Kudos
keferoff
Contributor
Contributor

Ballon Driver как раз таки и вытесняет в гостевой своп наиболее подходящие для этого страницы.

Спасибо за ценный коментарий! Где об этом можно прочесть? Я наоборот читал в доках что у балун драйвера нет возможности определить тип данных ОЗУ для перегрузки в своп.

0 Kudos
EGarbuzov
VMware Employee
VMware Employee

Почитать лучше всего тут. Начиная со страницы 23.

То, что вы путаете с балоном -- это своп гипервизора (своп второго уровня), о чём я писал выше. Вот он действительно потенциально может не знать, какие страницы памяти стоит выгружать, а какие нет. Другой вопрос, что если у вам уже настроен параметр Resrvation для всех машин на хосте, то на этом уровне свопиться будет просто некому

0 Kudos
Skyrod7
Expert
Expert

0 Kudos
Skyrod7
Expert
Expert

Установление лимита по памяти в ВМ как раз вызывает применение балунинга даже при наличии свободной памяти на сервере.

http://communities.vmware.com/people/Skyrod7/blog/2011/06/30/%D0%BE%D0%B1%D0%BE%D0%B7%D0%BD%D0%B0%D1...

0 Kudos
vMysh
Enthusiast
Enthusiast

как раз наоборот. Есть два механизма выделяющих странцы памяти в своп, грубо говоря. Наименьшее зло - балун. Т.к. именно он спрашивает ОЗУ гостя, какая страница не занята приложением.

0 Kudos
EGarbuzov
VMware Employee
VMware Employee

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

Установление лимита по памяти в ВМ как раз вызывает применение балунинга даже при наличии свободной памяти на сервере.

http://communities.vmware.com/people/Skyrod7/blog/2011/06/30/%D0%BE%D0%B1%D0%BE%D0%B7%D0%BD%D0%B0%D1...

Насколько я понял, были установлены не Limits, а Reservations

keferoff wrote:

EGarbuzov всё именно так как вы описали, я допустил неточности в терминологии когда описывал свою инфраструктуру.
0 Kudos
Skyrod7
Expert
Expert


Довольно странный сайзинг инфраструктуры - 5 серверов ESX 4.1 ( не просто так же их 5!), приложения, генерирующие серьезные ИОПСы (тоже не просто так) и "одна СХД с очень низким колличеством ИОПС"

Что-то здесь не так или не всё сказали

0 Kudos
keferoff
Contributor
Contributor

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


Довольно странный сайзинг инфраструктуры - 5 серверов ESX 4.1 ( не просто так же их 5!), приложения, генерирующие серьезные ИОПСы (тоже не просто так) и "одна СХД с очень низким колличеством ИОПС"

Что-то здесь не так или не всё сказали

Так сложилось исторически. Были задачи, а ресурсов на их выполнение небыло. Приходилось колхозить из того что было под рукой.

Сейчас идёт консолидация в плане уменьшения кол-ва серверов и увеличения их номинальной мощности. СХД тоже будет модернизирована с использование твердотельных накопителей. Но когда это всё будет...

А пока нашёл решение с уменьшением ИОПС на СХД.

Кстати, обьясните плиз если не трудно, что такое свопы первого и второго уровней?

Я всегда думал что своп первого уровня - это своп гостевой ОС. А своп второго уровня - это файл на в директории ВМ на СХД (.vswp) содержащий часть данных ОЗУ гостевой ОС вытесненных механизмом балун.

0 Kudos
Skyrod7
Expert
Expert

Почитайте must-read статью с ресурса vm4.ru по ссылке, приведенной мной выше. Многие вопросы отпадут.

P.S. Если у вас всего одна СХД, то почему не заиспользовать локальные стораджи хостов? Как временное решение?

Недавно нашел Virtual Appliance, делающее iSCSI-таргет на локальном сторадже - http://communities.vmware.com/people/Skyrod7/blog/2011/07/05/%D0%BB%D0%BE%D0%BA%D0%B0%D0%BB%D1%8C%D0... Если правильно всё организовать, то вполне жизнеспособное решение.

0 Kudos