Составной Случай Outlook Зависает

Этот случай был совместно использован со мной моим другом, Эндрю Ричардсом, Инженером Подъема Microsoft Exchange Server. Это - действительно интересный случай, потому что это выделяет использование утилиты Sysinternals, которую я определенно записал для использования службой поддержки Microsoft, и это - фактически два случая в одном.

Случай разворачивает с системным администратором при контакте корпорации поддержку Microsoft, чтобы сообщить, что пользователи через сеть компании жаловались на Outlook, подвешивает ­длительность до 15 минут. Факт, что многочисленные пользователи испытывали проблему, на которую указывают проблема Exchange, таким образом, вызов был направлен к службе поддержки Exchange Server.

Команда Exchange разработала набор коллектора данных Монитора Производительности, который включает несколько сотен счетчиков, которые оказались полезными для поиска и устранения неисправностей проблем Exchange, включая LDAP, RPC, и действие сообщения SMTP; количества соединения Exchange; использование памяти, и использование процессора. Поддержка Exchange сделала, чтобы администратор собрал журнал действия сервера с 12-часовыми циклами журнала, первое с 21:00 до 9:00 следующим утром. Когда инженеры службы поддержки Exchange, просматриваемые журнал, два образца были четкими несмотря на тяжелую плотность графиков: сначала и как ожидалось, загрузка Exchange Server, увеличенная в течение утра, когда пользователи вошли в работу и начали использовать Outlook; и во-вторых, встречные графики показали различие в поведении между около 8:05 и 8:20, продолжительность, которая соответствовала точно длинным пользователям задержек, сообщала.

Инженеры службы поддержки увеличили масштаб и ломали голову над счетчиками в период времени и могли видеть отбрасывание использования ЦП Exchange, активное количество соединения теряют работоспособность, и ­исходящая задержка ответа решительно увеличивается, но они были неспособны идентифицировать причину. (См. рисунок 17-28.)

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

ЦП зависает.

Рис. 17-28. Монитор производительности, показывая отбрасывание использования ЦП и увеличение задержки RPC.

Один способ получить дамп состоит в том, чтобы "присоединить" к процессу с отладчиком как Windbg от Средств отладки для пакета Windows (включенный с Комплектом разработчика программного обеспечения Windows) и выполнить.dump команду; однако, загрузка и установка инструментов, запуск отладчика, присоединение к правильному процессу, и сохранение дампов являются включенной процедурой. Вместо этого Эндрю, направленный администратор, чтобы загрузить ProcDump. ProcDump облегчает получать дампы процесса и включает опции, которые создают многократные дампы в указанном интервале. Эндрю, которого спрашивают администратора, чтобы выполнить ProcDump в следующий раз использование ЦП сервера, отброшенное так, чтобы это генерировало бы пять дампов процесса механизма Exchange Server, Store.exe, расположенный с интервалами на расстоянии в три секунды:

procdump-n 5-s 3 store.exe c:\dumps\store_mini.dmp.

На следующий день проблема была воспроизведена и администратор, отправленный Эндрю файлы дампа, которые генерировал ProcDump. Когда процесс временно зависает, это часто, потому что один поток в процессе получает данные защиты блокировки, что другие потоки должны получить доступ и содержат блокировку, выполняя некоторую продолжительную работу. Первый шаг Эндрю, поэтому, должен был проверить на сохраненные блокировки. Обычно используемая блокировка синхронизации внутрипроцесса - ­критический раздел, и! команда отладчика блокировок перечисляет критические разделы в дампе, которые блокируются, ID потока потока, имеющего блокировку, и число потоков, ожидающих, чтобы получить ее. Эндрю, используемый подобная команда! critlist от Sieext.dll отладчика extension3. Вывод показал, что многократные потоки были накоплены, ожидая потока 223, чтобы выпустить критический раздел.

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

Как иногда происходит, отладчик был неуверен, как интерпретировать стек, когда это сталкивалось со стековым фреймом, указывающим в Savfmsevsapi, изображение, для которого это не могло получить символы. Большинству изображений Windows отправили их символы на сервере символа Microsoft, таким образом, это было вероятно, сторонний DLL, загруженный в Exchange Store.exe, обрабатывает, и был ­поэтому подозреваемый в подвешивании. Модули списка (lm) команда выводят информацию о версии для загруженных изображений, и путь изображения, сделанного этим очевидный, что Savfmsevsapi был частью почтового продукта безопасности Symantec.

³ Общедоступная версия, SieExtPub.dll, может быть загружена с microsoft.com.

  

Преобразования

Эндрю, проверенный другие дампы, и у них всех были подобные трассировки стека. С неподтвержденной информацией, кажущейся указать на проблему Symantec, Эндрю, переданный на дампы и его анализ, с разрешением администратора, к технической поддержке Symantec. Несколько часов спустя они сообщили, что дампы, действительно показанные, проблема с ­последним антивирусным распределением подписи почтового ­приложения и передала патч к администратору, который исправит ошибку. Он применял это и продолжал контролировать сервер, чтобы проверить фиксацию. Конечно же, производительность сервера установленные довольно регулярные уровни активности и длинные задержки исчезла.

Однако, за последующие дни, администратор начинал получать, хотя на более низком уровне, жалобах от нескольких пользователей, что Outlook спорадически зависал в течение минуты. Эндрю, которого спрашивают администратора, чтобы отправить коррелирующее 12-часовое получение Монитора Производительности с набором сбора данных Exchange, но на сей раз, не был никакой очевидной аномалией.

Задаваясь вопросом, было ли бы подвешивание видимо в истории использования ЦП Store.exe, он удалил все счетчики за исключением счетчика использования процессора Хранилища. Когда он увеличил масштаб утренних часов, когда пользователи начали входить в систему и загрузка на увеличенном сервере, он заметил три шипа около 8:30 (См. рисунок 17-29.)

Рис. 17-29. ЦП пронзает в Store.exe около 8:30.

Поскольку у сервера есть восемь ядер, у счетчика использования процессора для отдельного процесса есть возможный диапазон между 0 и 800, таким образом, шипы были далеки от обложения налогом системы, но они были определенно выше чем типичный диапазон Exchange на той системе. Увеличивая масштаб далее и установка вертикали графика масштабируется, чтобы сделать шипы более отличными, он заметил, что среднее использование ЦП всегда было ниже приблизительно 75 процентов одноядерного, и шипы были 15-30 секунд длиной. (См. рисунок 17-30.)

Рис. 17-30. Увеличивание масштаб шипов ЦП.

Что Exchange делал во время шипов? Они были слишком недолгими и случайными для администратора, чтобы выполнить ProcDump как, он имел прежде, и достоверно получите дампы, когда они произошли. К счастью, я разрабатывал ProcDump с этим точным сценарием в памяти. Это поддерживает несколько триггерных условий, которые, когда встречено, заставляют это генерировать дамп. Например, можно сконфигурировать ProcDump, чтобы генерировать дамп процесса, когда процесс завершается или когда его частное использование памяти превышает определенное значение, или даже генерировать одно основанное на значении счетчика производительности Вы определяете. Его самый основной триггер, тем не менее, - использование ЦП процесса, превышающего указанный порог в течение указанного отрезка времени.

Журнал Монитора Производительности дал Эндрю информацию, он должен был обработать командную строку ProcDump, которая получит дампы для будущих шипов ЦП:

procdump.exe-n 20-s 10-c 75-u store.exe c:\dumps\store_75pc_10sec.dmp.

 

Параметры конфигурируют ProcDump, чтобы генерировать дамп Store.exe процесс, когда использование ЦП Хранилища превышает 75 процентов (-c 75) относительно одноядерного (-u) в течение 10 секунд (-s 10), чтобы генерировать до 20 дампов (-n 20) и затем выйти, и сохранить дампы в каталоге C:\Dumps с именами, которые начинаются с store_75pc_10sec. Администратор, выполняемый команда перед тем, чтобы оставлять работу, и когда он проверял ее продвижение следующим утром, это закончило создавать 20 файлов дампа. Он послал их по электронной почте Эндрю, который продолжился, чтобы изучить их в отладчике Windbg один за другим.

Когда ProcDump генерирует дамп, потому что триггер использования ЦП встречается, это устанавливает контекст потока в файле дампа к потоку, который использовал большинство ЦП во время дампа. Поскольку выводящие стек команды отладчика относительно контекста текущего потока, просто вводя команду дампа стека показывает стек потока наиболее вероятно, чтобы вызвать шип ЦП. Более чем половина дампов была неокончательной, очевидно ­полученный после того, как шип, который инициировал дамп, уже закончился, или потоками, которые выполняли код, который, очевидно, не был непосредственно связан с шипом. Однако, у нескольких из дампов были трассировки стека, подобные тому в рисунке 17-31.

Рис. 17-31. Store.exe сложите трассировку с хранилищем! TWIR:: EcFindRow+0xae.

Стековый фрейм, который перетерпел функцию EcFindRow перечисленного Хранилища, которая подразумевала, что шипы были вызваны долгими запросами базы данных, вид, которые выполняются, когда Outlook получает доступ к папке почтового ящика с тысячами записей. С этой подсказкой в руке Эндрю, предложенный администратора, создает материально-технические ресурсы больших почтовых ящиков и указал на него на статью, команда поддержки Exchange записала, что это описывает, как сделать это для каждой версии Exchange ("Находящий Высокий Элемент граф Фолдерс Используя управление Exchange Shell," доступный в http://msexchangeteam. com/archive/2009/12/07/453450. aspx).

 

Конечно же, сценарий, идентифицированный несколько пользователей с папками, содержащими десятки тысяч элементов. Администратор, которого спрашивают пользователей, чтобы уменьшить их количество элемента до значительно ниже 5000 (рекомендация Exchange 2003 года — это было увеличено в каждой версии с рекомендацией 100 000 в Exchange 2010), архивируя элементы, удаляя их, или организовывая их в подпапки. В течение нескольких дней они реорганизовали ­проблематичные папки и пользовательские жалобы, которые прекращают полностью. Продолжающийся контроль Exchange server за следующую неделю, подтвержденную, что проблема закончилась.

Со справкой ProcDump зависает составной случай Outlook, был успешно закрыт.