вторник, 28 июня 2011 г.

boot storm. TPS vs. hardware MMU



В комментариях к посту про page sharing - TPS vs. Large Pages in real life
- подсказали пару интересных ссылок.

Итак, суть вот в чем:
TPS позволяет нам сэкономить память, сэкономить заметно, особенно при отключении Large Pages.

После выключения Large Pages  потребляется на треть ОЗУ меньше 

Нагрузка на процессор вроде как растет, но если у вас (как у большинства) процессоры нагружены на 40 и менее процентов, то пофиг до небольшого роста.

Однако возникает опасения бут-шторма.
Так вот, по ссылкам из комментариев приводят данные тестирования ситуации бут-шторма.


Large Pages, Zero Pages, TPS and Boot-Storm in vSphere 4.x
Large Pages, Zero Pages, TPS and Boot-Storm Part II


Вводная:

Сервер с 32 ГБ памяти. Притом серверов два - старый и новый, с поддержкой аппаратной виртуализации памяти и без.
Типовая ВМ - Windows 2003 (а потом Windows 2008) с 4 ГБ памяти.

Что происходит при старте - Windows записывает нолик в каждую доступную страницу памяти, вроде как чтобы определить сколько памяти ей доступно.

Одновременно включалось 12 таких ВМ.

Вот он boot storm - гости одновременно хотят 48 гигабайт памяти, из 32 имеющихся.

Что происходит на сервере постарее, без аппаратной поддержки виртуализации памяти:


Как видно, как только произошел overcomitment а TPS не смог помочь его избежать - начали применяться механизмы вытеснения гостя из оперативной памяти (balloon\memory compression\vmkernel swap). Конкретно тут, почему-то, использовался своп гипервизора, а не balloon.

UPD. swap вырос аж до 3 мегабайт, видимо в самом начале, когда balloon-драйвер еще не загрузился. Потом не снижается с этих 3 мегабайт так как не было запросов к этой памяти.

Однако - и это узкое место данного теста - большая часть памяти занята не значимыми данными, а только нулями (на это указывает параметр acvtive memory). И раздутый swap оказывал влияние только(или в большей степени) на ненужные гостю страницы с нулями, т.е. провалов в производительности не было. Это-то хорошо, но непонятно как относится к реальной жизни.

Как видно из графика, ситуация стабилизировалась в течении 5-10 минут с момента старта.
А в течении 20 минут потребление памяти опустилось ниже 10 ГБ - за счет работы  TPS.

Для второго, нового сервера, чьи процессоры поддерживали аппаратную виртуализацию памяти, ситуация была иной:



Тут все просто офигенно - все свопы по нулям, память выделенная(consumed) и_не_поднималась(!) выше отметки в 10 ГБ.

Довольно важный вывод - на процессорах с аппаратным MMU ESX(i) не выделяет реальную память под нолики, просто "засчитывая" их гостю.

Это очень здорово, потому что если при бут-шторме не все гости будут потреблять сразу всю свою память, то даже без влияния TPS оперативка не будет тратиться впустую на обнуленные страницы.

10 комментариев:

  1. "Конкретно тут, почему-то, использовался своп гипервизора, а не balloon"
    возможно т.к. vm только стартовали vmware tools не запущены, драйвер memory balloon соответственно.

    ОтветитьУдалить
  2. тут график за час - "не верю!" (с)

    ОтветитьУдалить
  3. На первой картинке Swap Used остаётся стабильным несмотря на то, что Consumed << Host Memory уже спустя 10 минут после окончания boot storm. Чем объясняется такое поведение?

    ОтветитьУдалить
  4. мне тоже интересно, пока не понял сам.

    ОтветитьУдалить
  5. Нашёл объяснение в SDK:

    http://www.vmware.com/support/developer/vc-sdk//visdk41pubs/ApiReference/index.html

    Since swapped memory stays swapped until the virtual machine accesses it, swapped memory can be greater than the memory swap target, possibly for a prolonged period of time. This simply means that the swapped memory is not currently needed by the virtual machine and is not a cause for concern.

    ОтветитьУдалить
  6. В оригинальной статье указано что своп указан по правой стороне в мегабайтах, то есть там всего 4 Мб свопа. По идее уже спустя полторы минуты хосты распознали порядка 15-16 гб нулевой памяти (почти моментально), но так как все равно еще оставалось порядка 32 гб используемой памяти, то начался ballooning, к 16:22 уже набралось более 20 гб нулевой памяти и следовательно драйвер памяти сдулся да нуля. А вот своп так и остался висеть - если я не ошибаюсь, то своп вернется в RAM только в случае обращения к этому участку памяти внутри ВМ, потом по идее должно быть что то вроде page fault в ESX и только потом своп уйдет обратно в физическую память. Скорей всего к этим 3 мегабайтам никто не обращался в течение часа, ибо как Михаил уже отметил активная память нулевая, то есть машины вообще ничего не делают.

    ОтветитьУдалить
  7. "Притом серверов два - старый и новый, с поддержкой Large Pages и без." не совсем верно. Один который работает с памятью по старинке, через shadow page tables, а другой уже через EPT. Согласно документу VMware и на более старых процессорах будут поддерживаться Large Pages если для них включена поддержка в самой ОС/Приложении. А на новых процессорах ESX агрессивно использует Large Pages - опять же по словам Vmware. "Агрессивно" судя по статистике esxtop это видимо почти для всех ВМ, с какими то исключениями которыми с нами не поделились :)

    ОтветитьУдалить
  8. кстати да, про MMU\EPT и LP я слегка нагнал. сейчас поправлю.

    ОтветитьУдалить
  9. Не вижу свой вчерашний коммент (заскринен из-за ссылки?).

    Вот объяснение из SDK:

    Since swapped memory stays swapped until the virtual machine accesses it, swapped memory can be greater than the memory swap target, possibly for a prolonged period of time. This simply means that the swapped memory is not currently needed by the virtual machine and is not a cause for concern.

    ОтветитьУдалить
  10. сорри - блоггер не оповещает о том, что какой-то комментарий попал в спам, а я сам тоже не всегда это могу заметить.

    ОтветитьУдалить

Примечание. Отправлять комментарии могут только участники этого блога.