В этой статье речь пойдет о диагностике ситуаций, когда сервер замедляет работу или вообще перестает реагировать на действия пользователя из-за высокого коэффициента загрузки центрального процессора. Когда ресурсы процессора или процессоров сервера используются на 80-90%, работа серверных приложений замедляется или прекращается вовсе. В таких случаях приходится выяснять, какой именно процесс поглощает ресурсы центрального процессора.
Экран 1. Процессы, выполняемые центральным процессором.

Для этого требуется открыть утилиту Task Manager и щелкнуть на закладке Processes. На экране появится список активных процессов (см. Экран 1). Чтобы рассортировать процессы по показателю «использование центрального процессора», следует щелкнуть на заголовке столбца CPU. Из списка будет видно, какой процесс монополизирует время процессора. Если проблема связана с IIS, то «нарушителем» будет inetinfo.exe, внепроцессный (out-of-process, OOP) исполняемый файл dllhost.exe (Windows 2000) или mtx.exe (Windows NT 4.0). Если задействована служба Microsoft Indexing Service, то виновником высокого коэффициента использования центрального процессора может быть cidaemon.exe. Этот процесс создает и обновляет каталог Index, он обычно занимает много процессорного времени. Но cidaemon.exe работает с низким приоритетом, поэтому, как правило, не снижает производительность системы даже при высокой нагрузке на центральный процессор. Если процессор монополизирован любым другим процессом, то проблема, скорее всего, с IIS не связана.

Отыскав «виновника», можно собрать о нем дополнительные сведения. О том, как это сделать, рассказано ниже. Предполагается, что инструменты отладки на машине установлены. Также предполагается, что пользователь загрузил два дополнительных файла (debug.dll и debug.pdb) из библиотеки Code Library на Web-узле Windows Web Solutions (http://www.windowswebsolutions.com), установил и скопировал их в выбираемый по умолчанию каталог сценариев. Debug.dll и debug.pdb нужны для того, чтобы повысить коэффициент использования процессора до 100%. На самом деле файлы для диагностики проблем перегрузки процессора не используются. Следует убедиться, что виртуальный каталог сценариев для процесса доступен.

Сбор информации

Сначала необходимо запустить на сервере утилиту Performance Monitor и создать файл журнала Performance Monitor. Для этого на сервере Windows 2000 требуется выполнить следующие действия.

  • Развернуть узел Performance Logs and Alerts.
  • Щелкнуть правой кнопкой мыши на Counter Logs, затем выбрать пункт New Log Settings.
  • Ввести описательное имя файла журнала.
  • Запомнить местоположение файла журнала - это пригодится в дальнейшем (сменить местоположение файла можно будет после добавления объектов Performance, о которых я расскажу чуть позже).
  • Выбрать пункты All Counters и All Instances.
  • Выбрать из раскрывающегося списка Performance object (не забывая щелкать на кнопке Add после добавления каждого элемента): Active Server Pages, Memory, Process, Processor, Thread, Web Service, Internet Information Services Global.
  • Щелкнуть на кнопке Close.
  • Установить интервал 10, затем щелкнуть OK.

Чтобы создать файл журнала Performance Monitor на сервере NT 4.0, нужно выполнить следующие действия.

  • Выбрать пункт Log из меню Options.
  • Выбрать местоположение и имя файла журнала.
  • Установить интервал 1 (одна секунда).
  • Щелкнуть на кнопке Save.
  • Щелкнуть на значке (+) на панели инструментов.
  • Добавить следующие объекты: Active Server Pages, Memory, Process, Processor, Thread, Web Service и Internet Information Services Global.
  • Щелкнуть на кнопке Done.
  • Выбрать пункт Log из меню Options.
  • Щелкнуть на кнопке Start Log.

После того как будет создан файл журнала, следует дать серверу поработать 1-2 мин. Затем нужно открыть браузер и ввести с клавиатуры 

http://localhost/scripts/debug.dll?CPU
чтобы начать нагружать центральный процессор. По мере увеличения нагрузки система будет работать все медленнее.

Затем следует запустить Autodump+ (AD+ — один из инструментов отладки), используя синтаксис

cscript adplus.vbs -hang -iis -o
 <путь к файлу журнала>

Более подробная информация об AD+ приведена в статье Microsoft «HOWTO: Use Autodump+ to Troubleshoot 'Hangs' and 'Crashes'» (http://support.microsoft.com/default.aspx?scid=kb;en-us;q286350).

На сервере Windows 2000 следует щелкнуть правой кнопкой мыши на соответствующем журнале в Performance Monitor в разделе Counter Logs, а затем щелкнуть на Stop Log. На сервере NT 4.0 нужно выбрать пункт Log из меню Options в Performance Monitor и щелкнуть на Stop Log. После того как сбор данных для журналов будет остановлен, следует воспользоваться Task Manager, чтобы прервать процесс inetinfo.exe. К этому моменту в распоряжении пользователя будут файл журнала Performance Monitor и файл дампа inetinfo.exe и любых приложений OOP IIS.

Анализ информации

Теперь можно приступить к анализу файлов журнала и дампа. Ранее я уже рассказывал об объектах NT Synchronization Objects, которые активно используются IIS и потому важны для понимания причин перегрузки центрального процессора. Если поток ждет завершения работы другого процесса или поступления данных с диска либо из сети, то он, в сущности, ничего не делает. Поэтому программа, работающая в потоке, должна воспользоваться объектом NT Synchronization Object, чтобы перевести поток в состояние ожидания. Затем, после того как другой поток завершит работу или с диска поступят нужные данные, NT может «разбудить» ожидающий поток, и он продолжит свою работу. Пока поток находился в состоянии ожидания, он не использовал ресурсы процессора.

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

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

В Windows 2000 нужно открыть Performance Monitor, а затем щелкнуть на пиктограмме View Log File Data панели инструментов и выбрать файл журнала (см. Экран 2). Далее следует добавить счетчик коэффициента использования потоками центрального процессора. Диалоговое окно Add Counters открывается щелчком на пиктограмме Add Counters панели инструментов (см. Экран 3). Из раскрывающегося списка Performance Object следует выбрать Thread (поток). Установив флажок Select counters from list («выбрать счетчики из списка»), нужно выбрать пункт % Processor Time. Затем, установив флажок Select instances from list («выбрать экземпляры из списка»), можно выбрать все потоки inetinfo. Открыв консоль Performance Monitor, следует убедиться, что пиктограмма Highlight на инструментальной панели активизирована (см. Экран 4). Те же действия нужно выполнить и на сервере NT.

Экран 3. Добавление счетчиков.

Теперь можно просмотреть список счетчиков в нижней части окна, чтобы узнать, какой из них поглощает основную часть или все время центрального процессора. При активизированном режиме выделения белая линия на диаграмме соответствует счетчику, выбранному в нижней части окна. Белая линия интересующего нас потока будет все время занимать верхнее положение на диаграмме. Например, на Экране 4 проблемный поток имеет номер экземпляра 7. Следует запомнить, какой поток в данном тесте имел высокий результат.

Если обнаружен поток, который занимает много времени центрального процессора, но его доля в конце журнала уменьшается до 0% на несколько секунд, то, вероятно, в файле дампа не удастся обнаружить полезной информации об этом потоке. В файл дампа записывается один экземпляр в конце сеанса Performance Monitor, и поток, вернувшийся к показателю 0%, видимо, уже не связан с программой, которая перегрузила центральный процессор. Исключение из данного правила составляют потоки, коэффициент использования процессора которых падает в самом конце сеанса. Как правило, это происходит из-за того, что отладчик «замораживает» процесс, создавая файл дампа.

Теперь поток, который нужно исследовать, известен. Файл дампа можно загрузить в отладчик Windows Debugger (WinDbg). Чтобы перейти к нужному потоку, следует ввести с клавиатуры строку

<номер потока>s

(например, ~7s). Затем нужно ввести с клавиатуры

kb

чтобы получить стековый след потока. На экране должен появиться дамп, похожий на представленный на Экране 5. В наложенном сверху окне показан исходный текст фрагмента программы, исполняемой в потоке. Исходный текст отображается потому, что я скопировал debug.pdb, т. е. символы отладки, в тот же каталог, что и debug.dll. В других случаях наложенного окна может и не быть. В верхней части стека виден вызов, обращенный к debug.dll. Следовательно, эта DLL занимает все время центрального процессора. Если бы debug.dll была реальным приложением, работающим в системе, то можно было бы обратиться к программистам с просьбой устранить недостатки в его исходном тексте.

Диагностика без журнала

При отсутствии журнала Performance Monitor можно выяснить, что делают все потоки в файле дампа inetinfo.exe (команда для загрузки в дамп стеков всех потоков — ~*kb), чтобы отыскать виновника перегрузки. Следует помнить, что большинство потоков будет ждать завершения других потоков или поступления данных; эти потоки можно немедленно исключить. Один из следующих вызовов синхронизации в верхнем фрейме стека потока указывает на поток, который можно игнорировать:

  • NtRemoveIoCompletion;
  • Sleep;
  • SleepEx;
  • WaitForCriticalSection;
  • WaitForMultipleObjects;
  • WaitForSingleObject;
  • ZwRplyWaitReceivePort;
  • ZwUserGetMessage.

Это далеко не полный список; другие вызовы тоже могут свидетельствовать об отсутствии нагрузки на центральный процессор. Следует также помнить, что верхний фрейм стека пото-ка 0 в inetinfo.exe всегда показывает состояние ZwReadFile. Но поток 0 (и только он) в состоянии ZwReadFile не выполняет никакой работы. Можно предположить, что он не использует тактов центрального процессора.

Исследуя файлы дампов, полученные в периоды высокой загрузки процессора, можно определить, какой процесс (или процессы) использует все процессорное время. Нужно исключить все потоки, находящиеся в одном из перечисленных выше состояний, а затем взглянуть на оставшиеся потоки. Если файл дампа не дополнен журналом Performance Monitor, придется опираться на предположения, но список потоков почти всегда можно сузить, пока не отыщутся те потоки, которые перегружают центральный процессор.

Джефф Грей — инженер по обслуживанию группы Microsoft Alliance Support, специализирующийся на IIS. Имеет сертификат MCSE. С ним можно связаться по адресу: geoffgr@microsoft.com.