Может ли SysInternals Process Monitor регистрировать, когда поток блокируется в ожидании события?

Мне нужно диагностировать сервер, который не может достичь максимальной производительности. Использование ЦП падает до нуля примерно на 500 мс, а затем резко возрастает до 100% при попытке обработать запросы в очереди, этот шаблон повторяется в течение нескольких часов, после чего операция снова становится гладкой (операция была бесперебойной в течение многих лет)

Это говорит мне о том, что рабочие потоки простаивают в ожидании внешнего события. Приложение сложное, и мы не смогли точно определить виновника.

Можно ли настроить Process Monitor для записи в журнал каждый раз, когда поток приостанавливается в ожидании какого-либо события? Если возможно, может ли событие быть связано с определенной трассировкой стека?

Если вышеизложенное возможно, возможно, я мог бы сопоставить падения ЦП с событиями ожидания и точно определить виновника.

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


person BlueStrat    schedule 13.05.2020    source источник
comment
используйте ETW для диагностики: channel9.msdn. com/Shows/Defrag-Tools/   -  person magicandre1981    schedule 14.05.2020
comment
Ничего себе, это ИМЕННО правильный инструмент для работы. Хотел бы проголосовать за ваш ответ, если вы опубликуете его как таковой. Ваше здоровье!   -  person BlueStrat    schedule 15.05.2020
comment
хорошо, в этом случае я разместил ответ, чтобы вы могли принять мой ответ как ответ, чтобы закрыть вопрос.   -  person magicandre1981    schedule 15.05.2020


Ответы (1)


Windbg и ProcMon не подходят для этой работы. Установите Windows Performance Toolkit, который является частью Windows 10 SDK на устройстве разработчика.

введите здесь описание изображения

Теперь скопируйте папку C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit на сервер, откройте cmd.exe от имени администратора и запустите wpr.exe -start CPU && timeout -1 && wpr.exe -stop C:\Hang.etl, теперь сверните cmd.

После того, как вы освоитесь, вернитесь к cmd и нажмите клавишу, чтобы остановить ведение журнала.

Переместите папку Hang.etl + NGENPDB на ПК разработчика, откройте Hang.etl с помощью Анализатор производительности Windows (WPA.exe), загрузите символы отладки и запустите обнаружение зависания путем добавления CPU (Precise) в панель анализа

введите здесь описание изображения

и сделать кисло вы видите столбцы NewProcess, NewThreadId, NewStack, ReadyingProcess, ReadyingThreadId, ReadyingStack, Waits(us). Нажмите на Waits(us), чтобы увидеть самые длинные наверху. Теперь ищите долгое время с небольшим количеством Count (такие маленькие операции, которые занимают много времени, а не много операций) и проверяйте стек вызовов, чтобы понять, что происходит.

person magicandre1981    schedule 15.05.2020