Динамическая память в Hyper-V и файл подкачки
Несколько месяцев назад я написал статью о том, как работает динамическая память в Hyper-V R2 Service Pack 1. Закончил ту статью я мыслями на тему размера файла подкачки (pagefile) в виртуальных машинах, использующих динамическую память, не дав, однако, точной формулы. За это время я получил пару десятков вопросов о размере файла подкачки в почту, консолидировал информацию, и сегодня хочу обсудить результат. Предварительное чтение предыдущей статьи обязательно. Я не буду повторно объяснять все термины.
Итак, начнём с размера файла подкачки в виртуальных машинах. Ранее, до появления динамической памяти настройка была простой. Операционная система сама выставляла размер файла подкачки исходя из объёма памяти и наличия места на дисках, вы могли это значение уменьшать согласно известным формулам (о них также ниже). Теперь же при старте ОС объём памяти равен некому минимально заданному значению и увеличивается постепенно. Причём ни в какой момент времени гостевая ОС не знает ни о том, сколько потенциально памяти она ещё может получить, ни какое максимальное значение динамической памяти для неё выставлено. Для работы динамической памяти наличие файла подкачки в виртуальных машинах обязательно. При использовании виртуальными машинами всей доступной физической памяти сервера гипервизор начинает искусно манипулировать объёмами памяти, выделенной виртуальным машинам, уменьшая объём гарантированной памяти, что приводит к «надуванию воздушного шара» внутри виртуальных машин, созданию процесса, фиктивно потребляющего память, на деле отдающего её гипервизору. Остальные процессы в этом случае часть своей памяти при нехватке помещают как раз в файл подкачки. Строгой формулы, слепо применяемой ко всем машинам, не существует, вам следует провести некоторые исследования работы конкретной виртуальной машины, чтобы задать ей требуемый файл подкачки, не потребляющий десятки гигабайт на диске. Давайте рассмотрим процесс определения размера файла подкачки на простом примере.
Вы собираете информацию при помощи счётчиков производительности о работе вашей виртуальной машины. В любой момент времени вы знаете значение текущего гарантированного значения памяти (те, кто не знают что это такое, читают предыдущую статью). Нам интересно некое пиковое показание текущего гарантированного значения памяти за определённый промежуток времени, например, за неделю. Для машин со статическим объёмом памяти вы бы просто вычли из этого пикового показания объём статической памяти, добавили около 10% буфера и задали бы таким размер файла подкачки. Действительно, в этом случае больше не нужно, - можно смело уменьшать размер файла подкачки. Для машин с динамической памятью всё, в принципе, довольно таки схоже. Предположим, что для интересующей нас виртуальной машины мы наблюдаем следующую картину:
- Текущее гарантированное значение равно 1200 Мб
- Свободный буфер равен 20% (значение по умолчанию в свойствах для динамической памяти виртуальной машины)
- Пиковое значение текущего гарантированного значения (допустим, за неделю) равно 2000Мб
- Размер файла подкачки равен XXX Мб
- Предел гарантированной памяти равен 2000 + XXX Мб
- Свободной памяти 2000 + XXX – 1200 = 700 + XXX Мб
Нужно понять, каким задать объём файла подкачки XXX. Размер pagefile файла нужно задавать исходя из двух следующих правил:
- Его минимальный размер должен быть больше чем объём памяти, потребляемый в пиковой ситуации самым большим
- Его максимальный размер, как и в случае со статическим объёмом памяти может не превышать значения пикового показания текущего гарантированного значения памяти минус максимальное значение физической памяти, выделенное гипервизором данной виртуальной машине за тот же период мониторинга, плюс некий 10% буфер
Что произойдёт, когда некий процесс затребует больше памяти, чем объём свободной памяти, включая pagefile? Ничего хорошего, равно как и на физическом сервере, или в машине со статическим объёмом памяти, при попытке выделить памяти более чем есть свободной, произойдёт отказ. Система скажет о нехватке виртуальной памяти (на физическом сервере тоже) и не сможет выделить требуемый объём. Именно поэтому если вы берётесь за манипуляции с размером файла подкачки с целью экономии дискового пространства, следует провести детальной исследование работы ваших машин в течении некоторого срока.
Что можно сказать о размере файла подкачки на самом узле Hyper-V?
Как я уже рассказывал, с выходом Service Pack 1 мы можем резервировать некий объём физической памяти для использования строго ОС основного раздела при помощи параметра MemoryReserve. Hyper-V никогда не использует файл подкачки для виртуальных машин. Никогда. Так что, если вы выделите пару гигабайт при помощи MemoryReserve, то можете задать значение файла подкачки также плавающим: от 2 до 4 гигабайт. Более не понадобится. Очевидно, я исхожу из того, что кроме гипервизора, возможно антивируса и агентов управления на родительском разделе не установлено никакого серверного ПО и не настроены другие роли сервера.