Exchange Server 2013 – файл подкачки. Часть 2.


В первой части Exchange Server 2013 – файл подкачки. Часть 1 были выяснены рекомендации по настройке файла подкачки со стороны продуктовой группы. Интересно осмыслить эти рекомендации более глубоко. Начнём с простых истин.

Назначение файла подкачки

Первое

Файл подкачки по умолчанию всегда присутствует в системе и расширяет размер доступной памяти для приложений, образуя пул виртуальной памяти, который может в разы превышать размер оперативной памяти. Особенность работы операционной системы такова, что без файла подкачки очень высока вероятность возникновения нехватки оперативной памяти из-за пиковых захватов памяти приложениями. Почему приложения захватывают память пиками? Такова логика реализации алгоритмов в современных приложениях: создать массив объектов, захватив память, обработать их, захватив ещё больше памяти, завершить процедуру обработки, освободив и вернув память системе; повторить для других операций. Одновременно выполняется множество приложений, процессов, поэтому при отсутствии файла подкачки любая операция в приложении может завершиться ошибкой из-за отсутствия необходимой памяти, а приложение, как правило, завершается в этом случае аварийно. Например, вы заходите на сервер, открываете в Notepad лог-файл – всё нормально, но через несколько секунд IIS падает «в дамп» из-за нехватки памяти для какой-то операции, которую он начал выполнять в ответ на запрос пользователя.

Аксиома 1. Файл подкачки должен быть всегда.

О размере файла подкачки поговорим позже.

Второе

Файл подкачки предназначен для создания аварийных дампов. Дамп используется для анализа проблем как приложений, так и системы в целом. Соответственно размер файла подкачки должен быть достаточно большим, чтобы позволять создание дампа. Существует несколько видов дампов. Подробнейшее описание дампов и процесса их формирования в статье Understanding Crash Dump Files.

Тут есть два момента. Первый, заключается в том, что рядовой потребитель редко прибегает к анализу дампов: проблема и так локализуется достаточно просто – антивирус, плагин, драйвер и т.п., т.е. любой нестандартный дополнительный компонент; устраняется проблема в 95% случаев по одному рецепту: «Установите новую версию». Второй момент, если потребитель имеет контракты на техническую поддержку приложений, то очень вероятно, что разработчик потребует от него обязательного предоставления дампов для решения возникших проблем. Как правило такого уровня поддержка выполняется производителями по расширенным, т.е. очень дорогим, контрактам.

Аксиома 2. Если вы не имеете «расширенных» контрактов на поддержку, то дампы для вас бесполезны, если вы не занимаетесь самостоятельно их систематическим анализом.

Размер файла подкачки

Статический размер

Почему для Exchange Server рекомендуется делать файл подкачки статического размера? Представьте, что на системном диске сервера 30 Гб свободного места. Кажется, что всё прекрасно. Вдруг вы обнаруживаете, что сервер перестал обрабатывать почтовые потоки, и причина этого – на диске осталось всего 5 Гб свободного пространства. Куда делось место?! И вы видите файл подкачки гигантского размера: в системе что-то произошло, начался активный свопинг, рост файла подкачки и – доехали до отказа сервиса. Если бы файл подкачки ограничили в размерах, то какое-то приложение давно бы «грохнулось», а сервер мог бы работать дальше. (Этим приложением может быть, например, офлайн антивирус, мониторинг и т.п.). Вторая причина внезапного увеличения файла подкачки: так работает установленный по умолчанию Automatic memory dump. Максимальный рост до 3*RAM. При 10 Гб RAM файл подкачки может вырасти до 30 Гб, и в нашем примере сервер вообще останется с нулём свободного места на системном диске.

Вариантом может быть выделение под файл подкачки отдельного диска (или нескольких). Каких-то явных жирных плюсов в такой конфигурации нет, но есть её усложнение, а усложнение всегда жирный минус. Ещё одним «сложным» вариантом экономии пространства на системном диске является перенаправление различных подсистем самого Exchange с системного диска на дополнительные диски. Например, можно перебросить очереди сервиса HT; можно перенаправить логи на другой диск и т.д. Это действительно усложнение конфигурации. Есть ли в этом жирный плюс? Если параметры сервера выбраны в соответствии с официальными рекомендациями Technet и расчётами (Exchange Server Calculator), то никакой необходимости в подобном усложнении конфигурации нет: оперативной памяти и памяти на диске достаточно.

Поэтому Аксиома 3: делать статический файл подкачки на системном диске; если найдутся очень весомые аргументы, то на выделенном диске (дисках).

Виртуализация

Как влияет виртуализация? Виртуальная машина не имеет физического диска, и система производит операции ввода-вывода по сути через общий канал хоста (SAN, FC, 10G Ethernet). На другом конце стоит хранилище со своей системой управления и своими алгоритмами кэширования. Поэтому смысла в распределении нагрузки по нескольким дискам никакого нет, в том числе нет смысла в распределении файла подкачки по нескольким дискам. Тут многое (практически всё) зависит возможностей и настроек системы виртуализации и хранилища, а не от виртуальной машины. Остаётся добавить, что тенденция развития идет от «специальных» решений, средств и рекомендаций к «универсальным» и «интеллектуальным». Это ещё более укрепляет следующую аксиому.

Аксиома 4: виртуализация делает бессмысленным «распределение» нагрузки файла подкачки по нескольким дискам; нужно следовать рекомендациям производителя хранилища для получения оптимальных конфигураций в конкретной (по проекту!) системе виртуализации.

Размер

Теперь более подробно о размере. Наша цель – определить минимальный размер файла подкачки без негативных последствий для работы Exchange и системы в целом.

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

Определение размера файла подкачки сложное в теории, но легкое на практике. Сначала теория. Файл подкачки используется для 1. дампов и для 2. виртуальной памяти

Kernel dump size

Первым делом хочу обратить внимание на ключевой момент, который отмечен в выше упомянутой статье Understanding Crash Dump Files: по умолчанию полный дамп отключен. Теперь отметим, что на современных системах (2012 и выше) по умолчанию стоит настройка Automatic memory dump. Подробно описано в статье Windows 8 and Windows Server 2012: Automatic Memory Dump. По сути это Kernel Dump с некоторыми новыми «фишками». Всё это означает, что наличие полного дампа не является обязательным требованием для оказания технической поддержки.

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

Какие границы размера дампа ядра? Нижняя граница указана в статье Understanding Crash Dump Files, но она по сути бесполезна. Важна верхняя граница. Понятно, что ядро не занимает всю память: большую часть должны занимать приложения и кэши. Тем не менее верхняя гарантированная граница равна RAM+10Мб. Почему так много? Вспомните используемую в виртуализации технологию вытесняющего драйвера для возврата неиспользуемой памяти хосту: подобные драйверы могут увеличить размер ядра практически до размера оперативной памяти системы.

Аксиома 5: Ядро системы запускает внутри себя массу процессов и некоторые из них могут потреблять много оперативной памяти как любое другое приложение.

Как видите диапазон от минимума до максимума огромный, и максимум полностью зависит от особенностей конкретной системы. Поэтому рецепт простой: нужно вручную сделать дамп ядра и посмотреть его размер – это и будет наш реальный максимум размера дампа ядра. (Как это сделать описано в статье Microsoft KB Article 244139).

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

Надо отметить, что сам факт запуска Exchange на системе приводит к росту размера ядра системы в памяти. Причина в том, что Exchange запускает множество процессов, активно использующих ресурсы системы.

User dump size

Другая сторона — это приложение и размер пользовательского дампа. Тут все зависит от приложения. Так Exchange Server очень прожорлив и может занимать по свои нужды десятки гигабайт оперативной памяти и даже сотни. Тем не менее продуктовая группа говорит о предельном размере файла подкачки равном 32 Гб + 10 Мб. Почему так? Фактически Exchange Server это не монолитное приложение, а набор сервисов: множество изолированных процессов, каждый из которых представляет собой отдельное приложение. Продуктовая группа как бы говорит нам, что максимальный размер некоего самого большого процесса Exchange Server равен 32 Гб. Можно с большой степенью вероятности утверждать, что это процесс обеспечивающий доступ к почтовой базе (хотя может есть и другие прожорливые процессы (FAST например, точнее noderunner), но и для них рассуждение остаётся верным). Особенность Exchange Server 2013 в том, что подсистема ввода-вывода (управления почтовыми базами) не монолитный процесс как в предыдущих версиях: для каждой почтовой базы создаётся отдельный процесс. И получается, что его максимальный размер не превышает 32 Гб. В случае сбоя «в дамп» падает один такой процесс. Таким образом сколько бы почтовых баз и клиентов не обслуживал бы Exchange Server, максимальный размер пользовательского дампа будет 32 Гб + 10 Мб.

Более того, точно известно (Managed Store), что Exchange забирает под кэш баз только 25% памяти. Таким образом даже если все процессы управления почтовыми базами одновременно валятся в дамп, то размер дампа будет в районе 25% RAM.

Поиграем с цифрами. Пусть процесс Worker занимает 32 Гб. Максимум почтовых баз – 100. Процессы занимают 32Гб * 100 = 3.2 Тб памяти и это 25%. Тогда всего памяти 12.8 Тб – столько должно быть памяти на сервере, чтобы процесс управления почтовой базой достиг размера 32 Гб.

Точно известно, что система индексирования FAST (процессы noderunner) забирает под себя 15% памяти. Значит дамп не превысит этот размер.

Нам не составит никакого труда проверить эти цифры на живом сервере: достаточно запустить Task Manager, отобразить столбцы относящиеся к использованию памяти. Нам важны Working Set (Peak) и Commit Size – большее значение будет определять размер дампа процесса. Отсортируйте список процессов и этим столбцам. Картина ожидаемая: самые большие потребители – это процессы Microsoft.Exchange.Worker.exe и Noderunner.exe. и по сравнению с общим размером памяти эти процессы не так уж и велики.

Вывод 1. Если какая-то часть Exchange свалится в дамп, то размер дампа будет намного меньше размера оперативной памяти сервера.

Ignore dump

Только вспомним, что говорилось раньше: чаще всего дампы для нас бесполезны – поэтому эти оценки просто… интересны.

Memory Usage

Теперь сравните размеры Working Set (Peak) и Commit Size для каждого процесса Exchange: они примерно одинаковы для всех процессов. Это означает, что всё сидит в оперативной памяти и не сбрасывается в файл подкачки. Безусловно такая ситуация будет только в том случае, если сервер имеет достаточно оперативной памяти, а так будет если памяти столько, сколько рекомендуется и получается по расчётам (Exchange Server Calculator). Надо отметить ещё одну особенность процессов Exchange: система не сбрасывает в файл подкачки пассивные страницы этих процессов.

Посмотрим фактический размер файла подкачки на системном диске. В моём случае он оказался минимальным: равен минимальному размеру, заданному в настройках. Это составило 1 Гб. При этом счётчик производительности \Paging File(*)\% Usage показал использование 60% и в пике 80%. Причём файл подкачки использовали оснастки управления, которые я запускал на сервере.

Вывод 2. Если любите запускать на сервере кучу оснасток управления, да ещё несколькими администраторами – «любите» на сервере файл подкачки увеличенного размера.

Если учесть, что Exchange забирает под кэши фиксированные 40% памяти (25% под кэш баз и 15% под систему индексирования), то получается что Exchange работает так, чтобы не использовать файл подкачки вообще.

Вывод 3. Exchange не использует файл подкачки для своей работы.

Это при наличии рекомендуемого размера оперативной памяти. А что будет если памяти на сервере мало? Безусловно начнётся свопирование. И вполне предсказуемо, что Exchange будет добирать память до необходимого размера за счёт виртуальной памяти лежащей в файле подкачки. Но это уже особенность работы системы, а не Exchange.

Давайте поиграем с цифрами. Пусть сервер имеет расчетное значение памяти – 100%. Уменьшим на нём память вдвое до 50%. Понятно, что памяти Exchange-у уже не будет хватать. Сколько памяти Exchange окажется в файле подкачки? Исходные 40% кэша превращаются в 20%, остаётся 50%-20% = 30%, а при исходной памяти это равно 60%. Далее 60%-30% получаем 30% — столько от исходного размера памяти будет занято в файле подкачки при уменьшении памяти вдвое. (Например, исходная память 100Гб, оставляем на сервере 50 Гб, в подкачку уходит 30 Гб). Это именно «игра», потому что кроме Exchange есть другие процессы, и они имеют свою «динамику» использования памяти.

Интересно провести расчёт в обратную сторону. Если у вас Exchange свопит из-за недостатка оперативной памяти, например, на 5 Гб, то на сколько вам надо увеличить размер оперативной памяти на сервере? Пусть на сервере 10 Гб памяти. Из предыдущего абзаца ясно, что не на 5 Гб, а больше. Можете сами прикинуть, что памяти надо под 18 Гб.

Вывод 4 («игровой»). Для «ликвидации» свопинга Exchange в размере 1Гб нужно почти вдвое больше оперативной памяти!

Практика

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

Что нужно померить:

  1. Пиковые размеры процессов Exchange, IIS и Noderunner (working set peak, commint size)
  2. Пиковый размер файла подкачки
  3. Использование файла подкачки (\Paging File(*)\% Usage)
  4. Использование памяти (commit limit, commit charge)

На основе этих параметров можно достаточно точно и безопасно выставить статические границы файла подкачки. Нижнюю границу я бы рекомендовал установить не менее 1 Гб. Этого вполне хватит для системных процессов и интерактивных сессий администраторов. Что касается верхней границы, то опираясь на размеры указанных процессов, можно приблизить commit limit к значению commit charge, уменьшив размер файла подкачки.

Остаётся добавить, что эти рассуждения по оптимизации размера файла подкачки можно применить к серверам с другими приложениями.

Полезные ссылки:

  1. Windows 8 and Windows Server 2012: Automatic Memory Dump
  2. What is the Page File for anyway?
  3. Windows 8 / Windows Server 2012: The New Swap File
  4. How to use the DedicatedDumpFile registry value to overcome space limitations on the system drive when capturing a system memory dump
  5. Guidance on page file size X64 and X32 machines Windows 2003 servers
  6. Ask The Perf Guy: Sizing Guidance Updates For Exchange 2013 SP1
  7. Pushing the Limits of Windows: Virtual Memory
  8. What is the Page File for anyway?
  9. How to determine the appropriate page file size for 64-bit versions of Windows
  10. Tracking page file reads and writes
  11. How to determine the appropriate page file size on my server
  12. Working Set
Реклама

Один ответ

  1. […] Exchange Server 2013 – файл подкачки. Часть 2. […]

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: