Блог

Давайте рассмотрим простой случай — я запускаю консольное приложение .net5 в Windows. Если я получаю трассировки с помощью PerfView / threadTime collect, как описано здесь, тогда я вижу метрику BLOCKED_TIME на вкладке Временные стеки потоков. Как я должен запустить команду dotnet-trace, чтобы получить ту же метрику в Perfview? Я пытался играть с уровнем детализации, но пока безуспешно.

Короче говоря, вы не можете: (

Dotnet-trace использует профилировщик выборки, реализованный в .СЕТЕВОЕ время выполнения. Профилировщик запускается в отдельном потоке приложения и собирает кадры стека вызовов управляемых потоков каждые несколько миллисекунд. В отличие от большинства профилировщиков процессора, он собирает стеки вызовов даже для ожидающих потоков. Таким образом, посмотрев на стеки вызовов, вы можете оценить время ожидания управляемого потока. Например, на рисунке ниже мы можем видеть управляемый поток, ожидающий около 686 мс на ManualResetEvent.

Конечно, это только приблизительная оценка и зависит от интервала выборки. Вы также можете включить события пула потоков CLR и / или поставщика TplEventSource для получения событий, описывающих внутреннюю работу пула потоков и TPL.

Теперь перейдем к BLOCKED_TIME метрике в PerfView. Он основан на событиях ETW переключения контекста. Вы включаете их с помощью флажка «Время потока» в диалоговом окне коллекции PerfView:

Эти события генерируются системным планировщиком / диспетчером, когда на процессоре запускается новый поток. Они позволяют нам точно измерять время ожидания / выполнения потоков, но они также очень объемны.