Update High CPU Tutorial #29112
Update High CPU Tutorial #29112
Conversation
Initial changes to clarify tutorial
Show how perfview opens from step one.
This reverts commit 33a3a73. Images not needed
Updated counters section to follow a natural flow, increased detail regarding reasoning behind trace options and opening perfview.
|
|
||
| When analyzing a slow request, you need a diagnostics tool that can provide insights into what the code is doing. The usual choice is a profiler, and there are different profiler options to choose from. | ||
| When analyzing an app with high CPU usage, you need a diagnostics tool that can provide insights into what the code is doing. The usual choice is a profiler, and there are different profiler options to choose from. | ||
|
|
||
| ### [Linux](#tab/linux) | ||
|
|
There was a problem hiding this comment.
Should we explain why we suggest using the Linux perf tool and not dotnet-trace? I'm guessing the reason is something like: Although Dotnet-Trace is cross-platform but since Event Pipe "CPU" traces only measure elapsed time and not actual CPU time.
There was a problem hiding this comment.
I had the same question. @josalem Why are we using the Linux perf tool and not dotnet-trace?
There was a problem hiding this comment.
dotnet-trace is great for CPU investigations to a certain point. The limitations of safe-point bias and managed-only callstacks means that it can't give exact information the same way a kernel-aware profiler like perf can.
If your performance investigation stops at managed code, generally dotnet-trace will be sufficient. If you are analyzing exact timing of your application and it involves native code, you may need something like perf.
I think of it like two differently powered magnifying glasses. You can start with dotnet-trace and then look at a higher resolution using perf (or ETW on Windows).
Initial changes to clarify tutorial
Summary
Update tutorial for clarity
Fixes dotnet/diagnostics/2901