dotnet
[API Proposal]: provide profiling api like pprof of Go
Background and motivation
Go provides a neat api to expose profiling info net/http/pprof. When enabled, the package will expose an api /debug/pprof to list the following runtime profiling targets:
- allocs: A sampling of all past memory allocations
- block: Stack traces that led to blocking on synchronization primitives
- cmdline: The command line invocation of the current program
- goroutine: Stack traces of all current goroutines
- heap: A sampling of memory allocations of live objects. You can specify the gc GET parameter to run GC before taking the heap sample.
- mutex: Stack traces of holders of contended mutexes
- profile: CPU profile. You can specify the duration in the seconds GET parameter. After you get the profile file, use the go tool pprof command to investigate the profile.
- threadcreate: Stack traces that led to the creation of new OS threads
- trace: A trace of execution of the current program. You can specify the duration in the seconds GET parameter. After you get the trace file, use the go tool trace command to investigate the trace.
However, those features are still missing in the C#/.NET ecosystem.
API Proposal
HTTP GET /debug/pprof
API Usage
pprof could be a good example and guidance for this purpose.
https://github.com/google/pprof
Alternative Designs
No alternative for real-time profiling.
Risks
This API could live as a package, separate from the runtime implementation code.
See https://github.com/dotnet/dotnet-monitor
https://devblogs.microsoft.com/dotnet/announcing-dotnet-monitor-in-net-6/
Tagging subscribers to this area: @tommcdon See info in area-owners.md if you want to be subscribed.
Issue Details
Background and motivation
Go provides a neat api to expose profiling info net/http/pprof. When enabled, the package will expose an api /debug/pprof to list the following runtime profiling targets:
- allocs: A sampling of all past memory allocations
- block: Stack traces that led to blocking on synchronization primitives
- cmdline: The command line invocation of the current program
- goroutine: Stack traces of all current goroutines
- heap: A sampling of memory allocations of live objects. You can specify the gc GET parameter to run GC before taking the heap sample.
- mutex: Stack traces of holders of contended mutexes
- profile: CPU profile. You can specify the duration in the seconds GET parameter. After you get the profile file, use the go tool pprof command to investigate the profile.
- threadcreate: Stack traces that led to the creation of new OS threads
- trace: A trace of execution of the current program. You can specify the duration in the seconds GET parameter. After you get the trace file, use the go tool trace command to investigate the trace.
However, those features are still missing in the C#/.NET ecosystem.
API Proposal
HTTP GET /debug/pprof
API Usage
pprof could be a good example and guidance for this purpose.
https://github.com/google/pprof
Alternative Designs
No alternative for real-time profiling.
Risks
This API could live as a package, separate from the runtime implementation code.
| Author: | Banyc |
|---|---|
| Assignees: | - |
| Labels: |
|
| Milestone: | - |
With tools such as https://github.com/grafana/phlare or https://github.com/parca-dev/parca leveraging pprof and continuous profiling becoming a thing ( https://www.cncf.io/blog/2022/05/31/what-is-continuous-profiling/ ) it would be cool to see this.
Related demand on external nugget https://github.com/MiniProfiler/dotnet/issues/585
By the way if this API could be enabled / disabled without restart the whole process, that could be really awesome to avoid a constant overhead but being able to enable tracing programmatically when someone want or something seems interesting to profile. I don't know if it's doable in term of internal architecture.
It would be great to support this directly in dotnet-monitor, but until then I've made a small program that wraps the dotnet-monitor API to convert the CPU profiling data into the pprof format for integration with Grafana Phlare
https://github.com/multimac/dotnet-monitor-pprof-api
https://github.com/multimac/dotnet-monitor-pprof-api
@multimac - nice!
By the way if this API could be enabled / disabled without restart the whole process, that could be really awesome to avoid a constant overhead but being able to enable tracing programmatically when someone want or something seems interesting to profile. I don't know if it's doable in term of internal architecture.
@gillg - The underlying infrastructure to do profiling against .NET runtime supports doing profiling on demand, and at first glance I think @multimac's solution is also on-demand. You should be able to point it at any .NET Core app with no app code changes and no restart.
