Сервер Windows 2012 R2 Exchange 2013 Утечка памяти

Содержание

Вопрос или проблема
Ответ или решение
Ответ на вопрос о утечках дескрипторов и памяти в среде Exchange 2013 на Windows Server 2012 R2
Разница между утечками дескрипторов и утечками памяти
Утечка дескрипторов, не приводящая к утечке памяти
Потенциальные риски "чистой" утечки дескрипторов
Способы устранения проблемы
Заключение

Вопрос или проблема

У меня настроена DAG с сервером 2012 R2 и Exchange 2013, работающими на трех серверах, плюс еще один сервер для отставшей копии.

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

Утечка дескрипторов происходит из-за процесса Windows LSASS, что также создает проблемы, поскольку, хотя я и контролирую ситуацию с помощью Perfmon и использовал RAMmap, Process Explorer и т.д., это оказывается сложной задачей для диагностики, так как сам LSASS не является причиной; проблема заключается в том, что “использует” LSASS.

Я достаточно хорошо разбираюсь в диагностике производительности, но только в контексте внутреннего кодирования с использованием .NET и т.д.; все на этом сервере – Microsoft.

Так что, полагаю, мои вопросы следующие:

В чем разница между утечками дескрипторов и утечками памяти? Могу ли я столкнуться с утечкой дескрипторов, не имея утечки памяти? И если да, какова опасность чистой утечки дескрипторов со временем?

Что еще я могу сделать для диагностики? Я собирался установить SDK и использовать UMDH и Gflags для создания снимков памяти, но это не очень быстрая утечка, так что это будет немного болезненно.

У меня много информации, но не уверен, что она релевантна, так что, если вам нужно что-то уточнить, я могу предоставить.

Утечка дескрипторов – это особый случай утечки памяти. Вы теряете память из узко определенного пула: набора доступных дескрипторов. Обычно дескриптор – это указатель памяти, который на 64-битной машине занимает 8 байт. Так что 261076 дескрипторов умножить на 8 байт дает 2039kB, чуть меньше 2MB. Это мелочь для современных машин.

Но проблема, за которой вам нужно следить, это: что происходит, когда вы исчерпываете дескрипторы? Как ваше приложение деградирует? Есть ли жесткий предел или оно начинает ломаться до достижения максимума? Можете ли вы построить график количества дескрипторов и перезапустить службы, когда они превышают определенную точку? Есть ли способ изменить лимит на количество дескрипторов, чтобы смягчить проблему? Помогает ли перезапуск служб или требуется перезагрузка?

Ответ или решение

Ответ на вопрос о утечках дескрипторов и памяти в среде Exchange 2013 на Windows Server 2012 R2

Разница между утечками дескрипторов и утечками памяти

Утечка дескриптора — это частный случай утечки памяти, которая связана с исчерпанием доступных дескрипторов в системе. Дескрипторы — это структуры данных, которые представляют объекты, используемые процессом, такие как файлы, потоки и т.д. На 64-битной машине каждый дескриптор занимает 8 байт. При вашем количестве дескрипторов в 261076 это составляет около 2 МБ памяти, что для современных компьютеров является незначительным объемом.

Следует помнить, что проблема возникает, когда система начинает испытывать нехватку дескрипторов. При исчерпании лимита возможно ухудшение работы приложений — они могут начать аварийно завершаться или не смогут создать новые дескрипторы, что может привести к сбоям в работе Exchange.

Утечка дескрипторов, не приводящая к утечке памяти

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

Потенциальные риски "чистой" утечки дескрипторов

Исчерпание ресурсов: По мере увеличения числа дескрипторов в конечном итоге вы достигнете максимального лимита, что приведет к сбоям приложений и отказам в создании новых подключений.
Снижение производительности: Даже при наличии свободной памяти система может работать медленнее, поскольку она будет пытаться давать ресурсы тем процессам, которые испытывают нехватку дескрипторов.
Необходимость перезапуска: В некоторых случаях можно решить проблему, просто перезапустив службу или сам сервер, но это не является долгосрочным решением.

Способы устранения проблемы

Мониторинг и графики: Продолжайте мониторинг с помощью Perfmon, настраивая графики для отслеживания числа дескрипторов во времени. Установите порог, при превышении которого будут перезапущены соответствующие службы.
Выявление источника: Используйте такие инструменты, как Process Explorer или другие утилиты для отслеживания дескрипторов и определения процессов, которые их создают. Этот шаг наиболее критичен для выявления корневой причины утечки.
Установка SDK и использование UMDH: Хотя это может занять больше времени, установка SDK и использование UMDH и Gflags для создания снимков состояния системы поможет в дальнейшем анализе. Фокусируйтесь на время между созданием снимков и идентификацией роста дескрипторов.
Перезагрузка процессов: Если вы обнаружите, какой процесс вызывает утечку дескрипторов, рассмотрите возможность автоматизации его перезапуска, как временное решение.
Обращение в поддержку Microsoft: Если проблема не может быть решена, вы можете рассмотреть возможность получения помощи от поддержки Microsoft, предоставив им все собранные данные и логи, чтобы они могли помочь в более глубоком анализе.

Заключение

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