Назад | Перейти на главную страницу

Server 2012 R2 Exchange 2013 Обработка утечки

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

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

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

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

Итак, я предполагаю, что мои вопросы:

В чем разница между Handle Leaks и Memory Leaks. Могу ли я иметь Handle Leak без утечки памяти? И если да, то какова опасность чистой сверхурочной утечки информации?

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

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

Спасибо,

Чарльз

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

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