Сообщения
- подсказали пару интересных ссылок.
Итак, суть вот в чем:
TPS позволяет нам сэкономить память, сэкономить заметно, особенно при отключении 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 оперативка не будет тратиться впустую на обнуленные страницы.
Итак, суть вот в чем:
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 оперативка не будет тратиться впустую на обнуленные страницы.
"Конкретно тут, почему-то, использовался своп гипервизора, а не balloon"
ОтветитьУдалитьвозможно т.к. vm только стартовали vmware tools не запущены, драйвер memory balloon соответственно.
тут график за час - "не верю!" (с)
ОтветитьУдалитьНа первой картинке Swap Used остаётся стабильным несмотря на то, что Consumed << Host Memory уже спустя 10 минут после окончания boot storm. Чем объясняется такое поведение?
ОтветитьУдалитьмне тоже интересно, пока не понял сам.
ОтветитьУдалитьНашёл объяснение в 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.
В оригинальной статье указано что своп указан по правой стороне в мегабайтах, то есть там всего 4 Мб свопа. По идее уже спустя полторы минуты хосты распознали порядка 15-16 гб нулевой памяти (почти моментально), но так как все равно еще оставалось порядка 32 гб используемой памяти, то начался ballooning, к 16:22 уже набралось более 20 гб нулевой памяти и следовательно драйвер памяти сдулся да нуля. А вот своп так и остался висеть - если я не ошибаюсь, то своп вернется в RAM только в случае обращения к этому участку памяти внутри ВМ, потом по идее должно быть что то вроде page fault в ESX и только потом своп уйдет обратно в физическую память. Скорей всего к этим 3 мегабайтам никто не обращался в течение часа, ибо как Михаил уже отметил активная память нулевая, то есть машины вообще ничего не делают.
ОтветитьУдалить"Притом серверов два - старый и новый, с поддержкой Large Pages и без." не совсем верно. Один который работает с памятью по старинке, через shadow page tables, а другой уже через EPT. Согласно документу VMware и на более старых процессорах будут поддерживаться Large Pages если для них включена поддержка в самой ОС/Приложении. А на новых процессорах ESX агрессивно использует Large Pages - опять же по словам Vmware. "Агрессивно" судя по статистике esxtop это видимо почти для всех ВМ, с какими то исключениями которыми с нами не поделились :)
ОтветитьУдалитькстати да, про MMU\EPT и LP я слегка нагнал. сейчас поправлю.
ОтветитьУдалитьНе вижу свой вчерашний коммент (заскринен из-за ссылки?).
ОтветитьУдалитьВот объяснение из 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.
сорри - блоггер не оповещает о том, что какой-то комментарий попал в спам, а я сам тоже не всегда это могу заметить.
ОтветитьУдалить