Главная Virtualization, Windows, Без рубрики, Новое Memory Overcommitment: нужен или не нужен?
  • Memory Overcommitment: нужен или не нужен?

    До недавнего времени, на рынке серверной виртуализации безраздельно правила компания VMware. Фактически, у нее не было конкурентов – ну, разве что Citrix, после покупки Xen. Теперь же на этот рынок вышла и Microsoft с их Hyper-V и совсем недавно подтянулась и Red Hat с RHEV. И теперь «война» между вендорами решений виртуализации грозит по накалу страстей и своей эпичности перерасти даже священную войну адептов Microsoft и Linux. Одним из главных козырей в войне виртуализаторов являются принципы работы с памятью, и в частности – наверняка известный многим термин – Memory Overcommitment. Это как раз то, что, по словам адептов VMware, уже давно есть у них, и нет у Microsoft. В ответ на это, Microsoft вышла с Windows Server 2008 Service Pack 1, содержащим технологию Dynamic Memory. При этом они утверждают, что Dynamic Memory – это не Memory Overcommitment. Давайте же посмотрим, что же на самом деле скрывается под этими английскими словосочетаниями.

    VMware: Счастье для всех! Даром! Никто не уйдет обиженный!

    – Счастье для всех!.. Даром!.. Сколько угодно счастья!.. Все собирайтесь сюда!.. Хватит всем!.. Никто не уйдет обиженный!. Даром!. Счастье! Даром!..

    Аркадий и Борис Стругацкие, «Пикник на обочине»

    Компания VMware заслуженно является лидером на рынке серверной виртуализации для систем x86. Фактически, именно она основала этот рынок, и до определенного времени практически не имела конкурентов. Именно у них имеется замечательная технология Memory Overcommitment, которой так не хватает всем остальным игрокам рынка виртуализации. Так что же такое Memory Overcommitment? Если верить рекламным буклетам, эта особая, виртуализационная магия позволяет виртуальным машинам использовать больше памяти, чем имеется физически у сервера. Увы, термин этот был выдуман не столько техническими специалистами, сколько рекламщиками, и поэтому из одного названия сложно что-либо понять. Ну, примерно как какой-нибудь «триклозан» или «ксилит с карбамидом» в телевизионной рекламе. На самом деле, под Memory Overcommitment понимается сразу несколько технологий:

    • Вытеснение памяти (Ballooning)
    • Дедупликация страниц (Page Sharing)
    • Подкачка на уровне гипервизора (Second Level Swapping)
    • Компрессия памяти (Memory Compression)

    Попробуем рассмотреть эти технологии, и их достоинства и недостатки подробнее.

    Вытеснение (Ballooning)

    Работа этой технологии заключается в использовании специального драйвера, способного «вытеснять» неиспользуемую память путем «захвата» на себя адресного пространства. Адреса, занятые драйвером – не могут использоваться приложениями. Сама же память после такого захвата может быть отдана другим виртуальным машинам, при этом гостевая ОС об этом даже не догадывается – для нее память как была, так и осталась – только вроде как занята драйвером. Существует так же термин Preinflated Balloon. К примеру, виртуальной машине нужно выделить 2 Гб памяти – драйвер ballooning’а заранее «захватывает» адресное пространство на 1 Гб себе, а когда понадобится еще 1 Гб – эти адреса освобождаются. И получается, как в старом анекдоте – когда человеку, жаловавшемуся на тесноту – посоветовали привести в дом козу, а затем убрать ее – и дома у него стало очень хорошо и просторно.

    Хотя и суммарное выделение памяти для виртуальных машин при использовании ballooning’а и может превысить физический объем памяти сервера – фактически, использоваться будет именно столько, сколько есть. Остальное будет «захвачено» драйвером. Ballooning позволит запустить на одном физическом хосте немного больше виртуальных машин, но сам по себе этот алгоритм не позволяет виртуальным машинам использовать больше памяти, чем есть физически. Так что, ballooning – это еще не магия. Магия начнется дальше.

    Дедупликация страниц (Page Sharing).

    В многих современных ОС используется страничный принцип организации памяти. Это означает, если немного упростить, что при обращении к памяти информация отдается «порциями» – так называемыми страницами. Как правило, размер одной такой страницы – 4 килобайта. К примеру, если нам нужно прочитать 1 килобайт информации – мы все равно получим страницу в 4 килобайта. Если же мы попробуем, к примеру, считать 5 килобайт – то получим две страницы, то есть 8 килобайт.

    Алгоритм работы дедупликации следующий:

    1. Гипервизор проходит последовательно по всем страницам памяти и вычисляет их контрольные суммы. Эти контрольные суммы заносятся в таблицу.
    2. Все контрольные суммы в таблице сравниваются между собой и ищутся страницы с одинаковыми контрольными суммами.
    3. Страницы, у которых контрольные суммы совпадают – сравниваются побитово для нахождения полностью идентичных страниц.
    4. Вносятся изменения в таблицу соответствия гостевых (тех адресов, которые «видит» гостевая ОС) и физических адресов таким образом, что те гостевые адреса, которые ранее соответствовали идентичным страницам – будут указывать на одну и ту же физическую страницу, а все остальные идентичные страницы обнуляются и могут использоваться другими виртуальными машинами. До дедупликации таблица соответствия выглядит так: каждому гостевому адресу (GA) соответствует свой физический адрес (PA):image После дедупликации одной и той же физической странице может соответствовать несколько гостевых адресов: image При этом, как мы видим, некоторые страницы освобождаются и могут быть использованы другими виртуальными машинами.
    5. Если же в такую страницу одна из виртуальных машин попытается что-то записать – для нее создается отдельная копия страницы, и устанавливается соответствие с гостевым адресом.

    Вот так все просто, и никакой магии: благодаря использованию такого алгоритма виртуальные машины действительно могут использовать памяти больше, чем есть у сервера физически. Но есть и обратная сторона.

    Во-первых – как показала практика, эффективнее всего дедупликация работает с «пустыми» страницами, то есть с теми, которые не используются гостевой ОС и приложениями. Если виртуальные машины эффективно используют всю имеющуюся память – таких страниц будет немного.

    Во-вторых – новые процессоры поддерживают страницы большего размера – 2 Мбайт, вместо 4 Кбайт. Использование страниц большого размера позволяет использовать расширенные функции новых процессоров (такие, как прямое преобразование адресов – Intel EPT или AMD RVI), и повысить производительность за счет более эффективного кэширования адресов. Это особенно заметно при больших объемах памяти: само число 2-мегабайтных страниц будет намного, на порядки ниже, чем 4-килобайтных, и поэтому вероятность попадания в кэш будет намного выше. И здесь эффективность дедупликации очень сильно снижается, поскольку вероятность найти совпадающие побитово 2-мегабайтные страницы – намного ниже, чем при использовании 4-килобайтных страниц. Ну и кроме этого, дедупликация – процесс достаточно долгий (при больших объемах памяти может занимать часы) и ресурсоемкий. Поэтому дедупликация работает не непрерывно, а периодически.

    Подкачка на уровне гипервизора (Hypervisor Swapping)

    Как известно, многие современные ОС используют концепцию виртуальной памяти. Это означает, что приложения не «видят» физических адресов страниц в памяти. Они видят так называемые виртуальные адреса, которые затем могут быть преобразованы в физический адрес. Кроме этого, объем памяти в системе может расширяться за счет использования так называемых файлов подкачки. Страницы, к которым давно не обращались, могут быть выгружены в файл подкачки. В дальнейшем, при обращении к памяти по этому виртуальному адресу страница будет считываться не из памяти, а из файла подкачки на жестком диске. Некоторые гипервизоры так же позволяют выгружать в файлы подкачки память виртуальных машин.

    image

    Рассмотрим абстрактную виртуальную машину с абстрактной ОС на абстрактном гипервизоре. Пользовательские приложения, как мы знаем, не «видят» физических адресов. Вместо этого они обращаются к памяти, используя виртуальные адреса. Поскольку приложение запускается в гостевой ОС на виртуальной машине – мы говорим о гостевых виртуальных адресах (Guest Virtual Address, GVA). Затем диспетчер памяти гостевой ОС, при обращении по такому виртуальному адресу – отдает страницу, либо из памяти по физическому адресу (в нашем случае – гостевой физический адрес, GPA), либо из файла подкачки, хранящегося на жестком диске (SWAP).

    Поскольку речь идет о виртуальной машине – то имеется гипервизор, на котором она запущена. Гипервизор имеет таблицу преобразования, устанавливающую соответствие между гостевыми физическими адресами и системными виртуальными адресами (System Virtual Address, SVA). У гипервизора, в свою очередь, есть свой диспетчер памяти, который перенаправляет запрос либо по действительному, системному физическому адресу (System Physical Adress), либо точно так же – к странице в файле подкачки.

    Использование такой «двухуровневой подкачки» позволяет выделить виртуальной машине больше памяти, чем имеется физически. Но с одним «но»: как и при использовании файла подкачки в обычных ОС – это приводит к снижению производительности. Запись-чтение с жесткого диска всегда ниже, чем обращение к памяти. И если в обычной, «не виртуальной» ОС это может быть не так критично – то когда на одном физическом сервере запускается несколько десятков виртуальных машин, каждая из которых активно обращается к файлам подкачки – падение производительности может катастрофическим.

    Кроме того, при использовании «двухуровневой подкачки» возможны некоторые «курьезные ситуации», которые не могут возникнуть в «невиртуальных» ОС. Причина заключается в том, не все страницы можно свободно выгружать в файлы подкачки. Все ОС, использующие технологию виртуальной памяти – всегда знают, какие страницы можно выгружать, а какие нет. И поэтому, например, страницы, принадлежащие области памяти ядра – всегда останутся в памяти и никогда не попадут в файл подкачки. Гипервизор же не может знать, что именно происходит внутри гостевой ОС, и потому ему абсолютно все равно, какие страницы выгружать. И вполне возможна ситуация, что страницы памяти ядра, которые никогда не попадут в файл подкачки в гостевой ОС, будут выгружены на диск на уровне гипервизора. В результате, обращение к этим страницам будет проходить с достаточно большими задержками, что может вызвать очень сильное падение производительности, или даже «вылет» гостевой ОС со STOP-ошибкой.

    Но не только гипервизор не знает, что происходит в гостевой ОС. Гостевая ОС тоже не может узнать, какие страницы были выгружены на диск гипервизором, а какие – нет – и может произойти «двойная выгрузка», когда страница, которая уже была выгружена на диск гипервизором – будет еще раз выгружена в файл подкачки гостевой ОС. Это, хоть и не так катастрофично, как предыдущая ситуация – тоже не лучшим образом скажется на производительности.

    Сжатие памяти (Memory Compression)

    Интересный алгоритм, появившийся в VMware vSphere 4. Он работает совместно с «двухуровневой подкачкой» (см. выше) и позволяет улучшить производительность этого метода.

    Суть алгоритма заключается в том, что страницы памяти, выбранные гипервизором для выгрузки на диск (в VMware ESX они выбираются случайным образом) вначале проходят сжатие с помощью алгоритма компрессии (используется алгоритм, сходный с ZIP). Если страница сжимается на 50% и более – то она помещается в кэш. Когда кэш заполняется – наиболее «старые» страницы проходят декомпрессию и выгружаются в файл подкачки. На их место записываются новые сжатые страницы. VMware ESX не хранит страницы на диске в сжатом виде.

    Под этот кэш выделяется часть памяти сервера. В настройках ESX имеется Mem.MemZipMaxPct, который может принимать значение от 5 до 100, означающий размер кэша в процентах от суммы сконфигурированной памяти всех виртуальных машин, запущенных на сервере.

    Сам по себе этот алгоритм достаточно интересен – он позволяет использовать преимущества «двухуровневой подкачки», при этом снизив его недостатки. Тем не менее, для работы компрессии необходима дополнительная память для кэша, да и сама работа алгоритмов компрессии/декомпрессии наверняка отнимает какую-то часть процессорного времени.

    Ну а теперь – давайте посмотрим, что же нового предлагает Microsoft?

    Microsoft: Oversubscribe!=Overcommit

    Многие, кто использовал Hyper-V до недавнего времени, жаловались, что он не позволяет достичь той же гибкости, что и VMware. «Хитрые» алгоритмы распределения памяти у Hyper-V вплоть до недавнего времени отсутствовали как класс, и виртуальные машины могли получать жестко заданный объем памяти, который выделялся сразу при запуске гостевой ОС, и мог быть измене только при останове виртуальной машины. Многие находили это неудобным, несмотря на призывы Microsoft покупать дополнительную память вместо лицензий VMware. С выпуском Windows Server 2008 SP1, в Hyper-V добавляется новый функционал, и в том числе – новая технология распределения памяти, Dynamic Memory. Что же это такое – Dynamic Memory?

    По сути, она представляет собой сочетание уже описанного Ballooning’а с технологией «горячего добавления памяти» (Hot Add).

    Давайте посмотрим, как это работает.

    При использовании Dynamic Memory, объем памяти виртуальной машины определяется не одним параметром, а тремя: Startup RAM, Maximum RAM и Memory Buffer. При запуске гостевой ОС ей выделяется объем памяти, равный Startup RAM. Если такого объема памяти в наличии нет – то виртуальная машина отказывается стартовать. В гостевой ОС, при установке служб интеграции, работает драйвер DMVSC.SYS. Этот драйвер взаимодействует напрямую с диспетчером памяти гостевой ОС. Этот драйвер постоянно «докладывает» системе о том, сколько памяти потребляет сама гостевая ОС и все запущенные в ней приложения. Эти данные получает балансировщик памяти (Memory Balancer) – компонент стека виртуализации, работающий в хостовой ОС. Балансировщик вычисляет значение нагрузки (Memory Pressure) – то есть отношение потребления памяти к тому объему памяти, который фактически был выделен виртуальной машине. Кроме этого, балансировщик автоматически вычисляет пороговые значения нагрузки – минимальное и максимальное. Если нагрузка превышает максимальное пороговое значение – то виртуальной машине добавляется память с использованием механизма Hot Add RAM. При добавлении памяти учитывается собственно то, сколько памяти потребляется гостевой ОС и приложениями, и «запас», определяемый параметром Memory Buffer. Формула достаточно проста: требуемый объем равен потреблению памяти плюс запас, в свою очередь равным проценту от потребления памяти. Если же значение нагрузки опускается ниже минимального порогового значения – это означает, что излишек памяти можно «отобрать» с использованием Ballooning’a. Получается эдакий аналог коммунизма – «каждому по потребностям». Более подробно о механизме работы Dynamic Memory я напишу в отдельной статье.

    Использование Dynamic Memory позволяет повысить консолидацию – то есть запустить на физическом хосте больше виртуальных машин, чем можно было бы со статическим распределением памяти. Но нужно уяснить, что Dynamic Memory не позволяет делать то, что называют Memory Overcommitment. Хотя гостевые ОС и могут «видеть» больше памяти, чем есть у сервера физически – они не могут ее использовать. В Microsoft это называют Oversubscribing. Фактически же виртуальным машинам не может быть выделено больше памяти, чем есть на самом деле. И именно в этом и заключается разница между Oversubscribing и Overcommiting – как обычно, дьявол – в деталях.

    Самым главным достоинством Dynamic Memory – является именно то, что она не является Memory Overcommitment. Dynamic Memory позволяет перераспределять память между виртуальными машинами «на лету», при этом без возможного ущерба для производительности: виртуальные машины по-прежнему используют столько памяти, сколько есть. Никаких «волшебных» алгоритмов типа дедупликации, компрессии или двухуровневой подкачки не используется. Недостаток же заключается в том же самом: виртуальные машины не могут использовать больше памяти, чем есть у сервера – и поэтому нужно грамотно планировать объем памяти на хостах, особенно – в сценариях с отказоустойчивыми кластерами. Поскольку в отказоустойчивой конфигурации, при выходе из строя одного хоста – виртуальные машины перезапускаются на другом хосте – для запуска им всем потребуется память, и если ее будет не хватать – часть виртуальных машин не сможет запуститься. Overcommitment здесь, в принципе, мог бы помочь. Еще один недостаток Dynamic Memory – в ограниченном списке поддерживаемых гостевых ОС. Поскольку механизм Hot Add RAM требует работы напрямую с диспетчером памяти гостевой ОС, для работы Dynamic Memory необходимо установить в гостевой ОС интеграционные службы последней версии (или Service Pack 1, если гостевая ОС – Windows Server 2008 R2 или Windows 7). На данный момент поддерживаются все версии Windows Server 2008 R2, Windows 7 версий Enterprise и Ultimate и Windows Server 2003 всех версий. Возможно, поддержка Dynamic Memory появится в следующей версии Linux Integration Services, а это значит, что к списку поддерживаемых ОС добавятся RHEL и SLES, но официальной информации об этом у меня нет.

    Несколько слов в заключение

    На этом я попробую закончить мою попытку сравнения механизмов работы с памятью в гипервизорах от разных вендоров. Я намеренно рассматривал двух основных игроков на рынке – это VMware и Microsoft. Если кто-нибудь сможет рассказать о работе гипервизоров других вендоров – в частности, Citrix, Red Hat (RHEV) и других – буду рад, если напишите ответную статью. Спасибо за то, что оставались со мной, и поздравляю вас с наступающим (а кого-то – уже и с наступившим) Новым Годом.

    Похвалить или обматерить сей опус, а так же задать вопросы можно, по традиции, в комментариях. Заранее благодарен.

Комментарии

  1. Спасибо за внятное объяснение динамик мемори.
    Если позволите ссылкой дам взгляд слегка с другой стороны:
    http://www.vm4.ru/2010/08/memory-management.html

    С наступающим 🙂

  2. оффтоп.
    Хорошо когда есть здоровая конкуренция. Она положительно влияет на цену и функционал. Всех -с Новым годом!
    MS желаю появления настоящей кластерной системы в новом году, вместо костылей, функционала FT и продолжать догонять vmware. Являясь более-менее спецом по системе наиболее вероятного противника(vSphere)-желаю и этой замечательной компании утереть всем нос пятеркой:)

  3. > Хорошо когда есть здоровая конкуренция. Она положительно влияет на цену и функционал. Всех -с Новым годом!

    Присоединяюсь к поздравлениям! И да, здоровая конкуренция – это просто классно :)) Даже боюсь представить, что было бы, если бы не было MS – все бы сидели на макинтошах, в таком “анальном рабстве”, которое Балмеру даже не снилось 🙂

    Кстати, FT – фича IMHO не нужная, точно так же, как и Memory overcommitment 🙂 У всех бизнес-критичных приложений есть свой нативный функционал отказоустойчивости – кластеры у SQL, DAG в Exchange, и т.д. и т.п.

  4. Кстати, FT — фича IMHO не нужная, точно так же, как и Memory overcommitment,
    У всех бизнес-критичных приложений есть свой нативный функционал отказоустойчивости — кластеры у SQL, DAG в Exchange, и т.д. и т.п.

    Уважаемый Александр!
    Не хочу вступать с Вами в технический спор, так как не разбираюсь на данный момент в технологиях виртуализации MS, кроме connectix virtual pc:)
    Просто прошу Вас не делать таких юношески-максималистких выводов, как не нужность FT -и т.д, и т.п не так велико, как Вам кажется.
    Вспомните, как маркетологи MS недавно говорили -live migration не нужна!
    Когда же она появилась-стали говорить-это прорыв!!!
    Я, например, активно пользуюсь:), так же как и FT. А в 5-ке будет поддержка многопроцессорности в данной технологии.

    Так же погуглите термин “говнилки”

  5. > Не хочу вступать с Вами в технический спор, так как не разбираюсь на данный момент в технологиях виртуализации MS, кроме connectix virtual pc:)

    Могу лишь порекомендовать почитать статьи. Не обязательно мои. Можно, например, почитать блог Бена Армстронга http://blogs.msdn.com/virtual_pc_guy – там очень хорошо и подробно описывается. Кстати, респект – не всякий помнит название фирмы Connectix 😉

    > Вспомните, как маркетологи MS недавно говорили -live migration не нужна!
    Они этого не говорили. Они говорили, что она может и нужна, но очень малому числу заказчиков. Реальных задач, настолько критичных к дайнтайму – не так и много.

    > Когда же она появилась-стали говорить-это прорыв!!!
    Да ладно вам. На то они и маркетологи. Да вы на Apple посмотрите – казалось бы, еще один коммуникатор с тачскрином – а ведь как раскрутили-то! 🙂 Это их работа. Здесь же, точнее в этой статье – я пытаюсь разобраться в технической сути, оставив весь marketing bullshit за скобками.

    > Я, например, активно пользуюсь:), так же как и FT.
    Overcommitment, IMHO, придуман не для того, чтобы им активно пользовались, а чтобы выручить в экстремальной ситуации. Как например катапульта в самолете.

    > Так же погуглите термин «говнилки»
    Где вы их увидели?

  6. иногда это плюс – на днях сервер с 8 Гб памяти на hyper-v остановил одну из VM – вдруг не хватило памяти, было VM с 4Гб и VM с 3Гб проработали неделю и вдруг VM с 4Гб была остановлена и обратно запущена только после уменьшения памяти до 3 => 2Гб на гипервизор очень жирно, а esxi при этом наверное не остановил бы VM

  7. Саш, хорошая статья, доходчивая.

  8. @6
    Поставь туда SP1 RC и включи Dynamic Memory, разумеется в гостевых ОС надо обновить компоненты интеграции – и все нормально запустится.

    @7
    Спасибо 🙂 Думаю, после праздников таки выложу хорошую, годную статью про Dynamic Memory – только добро от редакции получу 🙂
    Кстати можете поздравить: https://mvp.support.microsoft.com/default.aspx/profile/alexander.kosivchenko

  9. > эффективность дедупликации очень сильно снижается, поскольку вероятность найти совпадающие побитово 2-мегабайтные страницы – намного ниже, чем при использовании 4-килобайтных страниц

    А по-моему, что 1/(2^4096), что 1/(2^2097152) – те еще шансы найти совпадающие страницы. Шарятся в подавляющем большинстве пустые страницы (забитые нулями).

    P.S. С Новым Годом! 🙂

  10. Хорошая статья и по существу 🙂

    Не буду спорить по поводу эффекта от дедупликации, так как не сильно в теме. Спросите Жбанкова – он несколько другие цифры приводил.

    По поводу Dynamic Memory можно глянуть тут – http://technet.microsoft.com/ru-ru/library/ff817651(WS.10).aspx
    Также Александр забыл упомянуть, что механизм компрессии памяти значительно повышает скорость работы с “второй” подкачкой – диском гипервизора.

  11. @9
    >Шарятся в подавляющем большинстве пустые страницы (забитые нулями).
    Вот в том и дело – в одном случае они шарятся, в другом – вытесняются за счет ballooning и передаются другим (Hot Add)

    @10
    > Спросите Жбанкова — он несколько другие цифры приводил.
    Кстати да. Странно, что его до сих пор тут нет – обычно он всегда появляется в любой статье о Hyper-V.

    > По поводу Dynamic Memory можно глянуть тут
    Будет после праздников хорошая статья. Как только договорюсь с журналом.

    > Также Александр забыл упомянуть, что механизм компрессии памяти значительно повышает скорость работы с «второй» подкачкой — диском гипервизора.
    Я думал, это само собой разумеется.

  12. @9
    >А по-моему, что 1/(2^4096), что 1/(2^2097152) — те еще шансы найти совпадающие >страницы. Шарятся в подавляющем большинстве пустые страницы (забитые нулями).

    Коллега, по поводу вероятностей Вы правы только с чисто математической точки зрения.
    Вы не учитываете, что страницы памяти не случайным образом забыты нулями и единицами, их содержимое обладает некоторой регулярностью, в частности фрагментами повторяющегося кода.
    Так что вероятность на самом деле существенно выше. 😉

  13. > страницы памяти не случайным образом забыты нулями и единицами, их содержимое обладает некоторой регулярностью, в частности фрагментами повторяющегося кода.

    В этом случае фактическая вероятность не сильно отличается от вероятности для 4-килобайтных страниц 🙂

  14. Всех с прошедшими праздниками.

    Почему в статье не озвучен механизм резервации памяти в ESX, если не ошибаюсь с помощью этого механизма можно добиться того, что вся память виртуалки будет находиться в физическом пространстве хоста и к памяти машинки будет применяться только дедуплекация. Почему не упамянули, что механизмы вытеснения включаются только после появления борьбы за ресурсы.
    на мой взгляд, термин “грамотное планирование” следовало вынести в резюме, потому как без него можно получить кучу проблем и без виртуализации.

    Всем успеха в работе

  15. Кстати, свежая статья в тему от гуру виртуализации Duncan Epping:
    http://www.yellow-bricks.com/2011/01/10/how-cool-is-tps/
    Краткий вывод такой: TPS (Page Sharing) “рулит” и в Windows Server 2008 c Large Pages.
    Счастье для всех!.. Даром! 🙂

  16. Да, вот только видно, что шарятся только нулевые страницы. Само то, что таких страниц много – значит лишь то, что память можно было бы использовать чуть более эффективно. Если при “маленьких страницах” есть шанс “пошарить” еще что-то кроме пустых страниц – то с “большими страницами” “шарятся” только нулевые.

  17. Александр, механизмы TPS + ballooning, хороши еще и тем, что нет необходимости САМОМУ слишком много усилий тратить на то чтобы “память можно было бы использовать чуть более эффективно” – балансировка динамическая. Да, у Microsoft теперь это тоже есть.

    Направленность статьи Эпинга ИМХО в том, что скептики предрекали смерть TPS с появлением больших страниц, но как выясняется хоронить пока рановато – TPS “рулит” и с ними. 😉

  18. Автор, dynamic memory появился в 2008 R2 SP1, а не в 2008 SP1.
    Это две совершено разные операционные системы.

  19. Автор, dynamic memory появилось в 2008 R2 SP1, а не в 2008 Sp1.
    Это две совершенно разные ОС.

  20. А подскажите, что произойдёт если мы на всех гостях заюзаем всю выделенную им память(к-ая в сумме больше чем имеет физ. хост) ?
    с CPU overcommitment ещё понятно, а с Memory… – Приложения посыпятся?