Ссылка на оригинал: Team Virtualiazation Blog.
======================================================
Предисловие: Суть этой серии публикаций и дух в котором они написаны, должны показать комплексный подход к вопросам, стоящим перед нашими клиентами, обсуждение сложностей, связанных с управлением памятью, и объяснение почему для решения этих проблем мы выбрали динамическую память Hyper-V (Hyper-V Dynamic Memory). Это не обозначает критику кого-либо или каких-либо технологий, это проведение открытого и прозрачного обсуждения проблем.
======================================================
В моей последней публикации, мы рассмотрели некоторые оставшиеся вопросы связанные со страничным распределением. Сегодня мы рассмотрим второй уровень подкачки. Чтобы обсудить результаты использования второго уровня подкачки, давайте оставим виртуализацию в стороне, сделаем шаг назад и начнем с обсуждения виртуальной памяти и подкачки.
Современные операционные системы используют виртуальную память. Виртуальная память представляет способ увеличения эффективного объема памяти компьютера, за счет использования дискового файла (как области подкачки) для имитации дополнительного объема памяти. Операционная система отслеживает адреса памяти, которые на самом деле располагаются в памяти и какие должны быть привлечены с диска в случае необходимости. Вот несколько общих функций управления памятью, реализуемых современными операционными системами:
- Разрешение сосуществования нескольких приложений в физической памяти компьютера (реализация изоляции).
- Использование виртуальной адресации, для того чтобы скрыть управление физической памятью от приложений.
- Расширение системной памяти за счет подкачки.
Давайте погрузимся в глубины. Для этого, я буду ссылаться на статью TechNet, в которой обсуждается диспетчер виртуальной памяти Windows. Если вы желаете прочитать статью целиком, то она здесь: http://technet.microsoft.com/en-us/library/cc767886.aspx. Второй статьей я настоятельно рекомендую публикацию о виртуальной памяти от Марка Руссиновича: http://blogs.technet.com/markrussinovich/archive/2008/11/17/3155406.aspx.
Из статьи TechNet:
Распределение физической памяти компьютера.
Операционные системы, которые поддерживают многозадачность, позволяют программному коду и данным от различных приложений существовать в физической памяти компьютера (оперативная память [random access memory]) в одно и то же время. В обязанности операционных систем входит контроль за тем, чтобы физическая память распределялась настолько эффективно, насколько это возможно и чтобы память не расходовалась в пустую. В результате диспетчер памяти операционной системы вынужден бороться с проблемой, называемой фрагментация памяти. Фрагментация памяти относится к ситуации, когда свободная (доступная) память разбивается на маленькие разрозненные части, которые не являются достаточно большими, чтобы они могли быть использованы приложениями. В примере, обсуждаемом здесь, свободная память разделена на три отдельных блока:
После того, как физическая память становится фрагментированной, операционная система может объединить свободную память в единый непрерывный блок, перемещая блоки кода и данных в новые физические адреса. В этом случае три блока свободной памяти объединятся в один большой блок, за счет перемещения приложения по физической памяти.
Если некоторое приложение обращается к своему коду или данным, приложение может столкнуться с проблемой, когда операционная система перемещает этот код и данные. Механизм должен предоставить приложениям доступ к их коду и данным, даже в том случае, когда операционная система перемещает их в физической памяти.
Виртуализация доступа к памяти.
Распространенным решением является предоставление приложениям логического представления памяти (также часто называемой виртуальной памятью), которое полностью скрывает управление памятью операционной системой. Виртуальная память - это иллюзия, которую операционная система предоставляет приложениям для упрощения просмотра памяти. Приложения рассматривают виртуальную память так, как будто она является физической. Таким образом, операционная система может перемещать код и данные в физической памяти по мере необходимости.
В системе виртуальной памяти, адрес приложения использует виртуальные адреса для доступа к памяти, а не адреса физической памяти. Каждый раз, когда приложение обращается за доступом, используя виртуальный адрес, операционная система тайно переводит виртуальные адреса в физические, где на самом деле в физической памяти и находятся запрашиваемый код и данные. Так как перевод виртуальных адресов в физические осуществляется операционной системой, приложение не располагает информацией об истинном расположении кода и данных.
Расширение виртуальной памяти за счет подкачки.
Когда приложение обращается к памяти используя виртуальные адреса, операционная система отвечает за перевод виртуальных адресов в физические. В результате операционная система имеет тотальный контроль над тем, где данные и код физически хранятся. Это не только означает, что операционная система может перемещать код и данные в физической памяти на свое усмотрение, это также означает, что код и данные не обязаны целиком хранится в физической памяти.
Процессор компьютера может получить доступ только к коду и данным расположенным в физической памяти (RAM). Однако, физическая память стоит довольно дорого, поэтому многие компьютеры обладаю довольно малым объемом физической памяти. Многие многозадачные системы расширяют схему управления своей физической памятью, для компенсации недостатка физической памяти. Они полагаются на простой но очень важный факт: код и данные должны быть в физической памяти только тогда, когда процессор нуждается в доступе к ним! Когда процессор не обращается к данным, код и данные могут быть временно сохранены на жесткий диск (или другое устройство с большим объемом свободного места). Это освобождает физическую память для заполнения другим кодом и данными, к которым процессор желает получить доступ. Процесс временного перемещения кода и данных на жесткий диска и с него для освобождения физической памяти называется подкачкой.
Подкачка делается для увеличения объема виртуальной памяти, доступной на компьютере. Диспетчер памяти производит подкачку "за кулисами", в результате получается так, как будто компьютер имеет больше физической памяти, чем есть на самом деле. Фактически, виртуальная память, доступная на компьютере, равна физической памяти плюс все место на жестком диске, которое диспетчер виртуальной памяти использует для временной записи кода и данных.
Загрузка выгруженного кода и данных по требованию.
Если приложение пытается получить доступ к коду или данным, которые не находятся в физической памяти (которые выгружены на диск) диспетчер виртуальной памяти забирает управление. Диспетчер виртуальной памяти находит (или создает) доступные блоки свободной памяти, затем копирует необходимый код и данные в эти блоки, так чтобы они были доступны. Приложения не знают куда именно на диск были выгружены код и данные. Код и данные автоматически загружаются в физическую память диспетчером виртуальной памяти, когда приложение нуждается в их использовании.
Ключевые моменты:
- Управление памятью операционной системы абстрагирует физическую память приложений и обеспечивает изоляцию.
- Диспетчер памяти расширяет объем системной памяти за счет подкачки.
Отлично, теперь, когда мы обсудили как виртуальная память и подкачка работают, давайте свяжем это с виртуализацией.
Сегодня с Hyper-V (V1 & R2), память статично назначается на виртуальную машину. Это означает, что вы назначаете память виртуальной машине и когда она включена Hyper-V выделяет и предоставляет эту память виртуальной машине. Эта память удерживается до тех пор пока виртуальная машина запущена или приостановлена. Когда виртуальная машина сохраняется или выключается эта память освобождается. Ниже приведен снимок того, как сегодня происходит назначения памяти виртуальной машине:
Эта память 100% хранится в физической памяти и никогда не выгружается в область подкачки. Помните, что гостевая операционная система активно определяет какие страницы должны, а какие не должны выгружаться в область подкачки, так как она управляет всей памятью выделенной виртуальной машине и ей лучше знать, как это делать. Вот простая схема, которая позволяет проиллюстрировать то, как это выглядит в виртуальной среде. Есть четыре запущенные виртуальные машины и ядро каждой гостевой операционной системы управляет собственной памятью.
Хорошо, давайте теперь погрузимся на второй уровень подкачки.
Второй уровень подкачки (Second Level Paging, SLP) - это технология, в которой платформа виртуализации создает второй уровень абстракции памяти и в момент перегрузки системы выгружает файлы, созданные на уровне виртуализации в область подкачки на диск. С SLP, вы имеете два яруса подкачки на диск: один расположен в гостевой операционной системе и еще один расположенный ниже на уровне виртуализации. Вот еще одна схема, которая иллюстрирует то, как второй уровень подкачки размещается. Вновь, есть четыре запущенные виртуальные машины и каждое ядро гостевой операционной системы управляет своей собственной памятью. Однако, заметьте, что ниже, расположен второй уровень подкачки, которым независимо управляет платформа виртуализации.
Один из распространенных доводов в пользу второго уровня подкачки, который я слышал это: "Если Windows и другие современные операционные системы используют подкачку сегодня, тогда почему это плохо для использования с виртуализацией?"
Хороший вопрос.
Ответ: Производительность.
Со вторым уровнем подкачки, память, выделенная виртуальной машине, может быть размещена в памяти или на диске. В результате второй уровень подкачки создает уникальные проблемы в виртуальной среде. Когда система перегрузится уровень виртуализации может и будет вслепую, случайным образом выгружать на диск содержимое памяти гостевой операционной системы, в том числе и критические секции, которые ядро гостевой операционной системы специально держало в оперативной памяти в целях производительности. Вот что я имел в виду.
Выгрузка ядра гостевой системы это пример, в котором виртуализация создает проблему, которой не существует в физических системах. В ядре операционной системы есть специальные области, которые ядро операционной системы никогда не выгружает на диск в целях увеличения производительности. Это тема, в которой Microsoft и VMWare согласны друг с другом и VMWare много раз заявляет об этом в своей документации.
«...подкачка гипервизора это гарантированная технология освобождения определенного объема памяти в течении определенного времени. Однако, подкачка гипервизора, может серьезно отразиться на производительности гостевой системы. Это происходит в тот момент, когда гипервизор, не обладая сведениями о том что хранится в страницах физической памяти гостевой системы, выгружает их, и такая выгрузка может привести к непредвиденным взаимодействия с родной политикой управления памятью гостевой операционной системы. Для примера, гостевая операционная система никогда не выгружает страницы ядра, поскольку они имеют решающее значение в производительности ядра операционной системы. Гипервизор, в свою очередь, не может определить, какие страницы памяти принадлежат ядру и поэтому он может выгрузить их. В дополнение, гостевая операционная система восстанавливает чистые страницы буфера, путем их сброса. Опять же, поскольку гипевизор не может определить чистые страницы буфера гостевой системы, это может привести к бесполезной выгрузке их на устройство подкачки гипервизора, для того, чтобы вернуть физическую память хоста.»
Понимание управления ресурсами памяти в VMware ESX Server стр. 9-10;
http://www.vmware.com/resources/techresources/10062
Итак, чем больше вы превышаете объем памяти, тем хуже общая производительность, потому что система проигрывает используя диск, обладающий меньшей производительностью, чем память. Поговорим о сравнении производительности памяти и диска...
Наконец, сравнение производительности, или, если быть точнее, отсутствие сравнения, потому что не может быть никакого сравнения между памятью и диском. И это бесспорно. Это факт. Давайте немного посчитаем. Предположим, что у типичного диска время отклика составляет ~8 миллисекунд. А время отклика при доступе к памяти измеряется в наносекундах:
- DDR3-1600 = 5 наносекунд
- DDR3-1333 = 6 наносекунд
- DDR3-1066 = 7.5 наносекунд
- DDR3-800 = 10 наносекунд
Так что, если вы хотите сравнить доступ к диску с доступом к памяти DDR-3 1600, то формула выглядит следующим образом: 0,008/0,000000005. Здесь приведены результаты вычислений:
- Память DDR3-1600 в 1600000 раз быстрее чем диск.
- Память DDR3-1333 в 1333333 раза быстрее чем диск.
- Память DDR3-1066 в 1066666 раз быстрее чем диск.
- Память DDR3-800 в 800000 раз быстрее чем диск.
Мы много раз слышали, как пользователи виртуализации говорят, что производительность второго уровня подкачки "не так уж плоха". Я не знаю как можно говорить, с серьезным выражением лица, что разница в производительности в 6 десятков не так уж плоха. Можно ли отбросить перспективу в 1,6 миллионов раз, предположим вам требуется час на одну милю ходьбы. Если вы можете путешествовать в 1,6 миллиона раз быстрее, вы могли бы совершить путешествие к Сатурну и обратно за этот час. (Сатурн расположен на расстоянии примерно 746 миль от Земли.)
Microsoft и VMWare согласны друг с другом: Избегайте превышения объема.
Это факт, что подкачка на диск существенно снижает производительность и вы должны предотвращать это, нужно отметить что это еще одна область, в которой Microsoft и VMWare согласны друг с другом. Это не новое руководство, поэтому я включил примеры из ESX 3 и VSphere.
Из VMWare:
Пример 1: Убедитесь что хост обладает большим объемом физической памяти, чем будет использовано ESX вместе с суммарным объемом рабочей памяти, используемой всеми виртуальными машинами в любое время.
--Performance Tuning Best Practices for ESX Server 3 [Лучшая практика настройки производительности для ESX Server 3].
Пример 2: Если рабочий объем памяти настолько велик, что активные страницы постоянно выгружаются и загружаются (высок объем обмена станицами с областью подкачки), то это может привести к значительному снижению производительности. Чтобы избежать подкачки в конкретной виртуальной машине, пожалуйста настройте резервирование памяти для нее (через VI Client) по крайней мере равный объему рабочей памяти. Но будьте осторожны, потому что настройка резервирования ресурсов может сократить число виртуальных машин, которые вы можете консолидировать в системе.
--Performance Tuning Best Practices for ESX Server 3 страниа 15 [Лучшая практика настройки производительности для ESX Server 3].
Пример 3: ESX, также использует подкачку на уровне хоста, для того чтобы вернуть память из виртуальной машины. Так как это будет выгрузка активных страниц, это существенно снизит производительность виртуальных машин.
--Performance Tuning Best Practices for VSphere страница 23 [Лучшая практика настройки производительности для VSphere].
Вывод: Убедитесь, что память используемая ESX и ее виртуальными машинами расположена в физической памяти и избегайте подкачки на диск, то есть избегайте превышения объема памяти.
- Второй уровень подкачки нарушает фундаментальное предположение о том, что гостевые операционные системы имеют точное представление о физической памяти.
- Производительность памяти по отношению к диску от 800000 раз до 1600000 раз быстрее.
- Когда система превышает объем памяти, второй уровень подкачки может нанести существенный удар по производительности. Проще говоря, чем больше система превышает объем памяти, тем больше он выгружает на диск и это приводит к падению производительности всей системы.
Хорошая новость заключается в том, что существуют и другие методы выделения и размещения памяти и Hyper-V Dynamic Memory - это хорошее решение для настольных и серверных операционных систем... В моей следующей публикации мы будем обсуждать Hyper-V Dynamic Memory.
Ура,
Jeff Woolsey
Principal Group Program Manager
Windows Server, Virtualization
Несколько неверный текст ссылочки:
ОтветитьУдалить(Сатурн расположен на расстоянии примерно 746 миль от Земли)