Expose setting CPU SamplingProfiler rate

vaind commented 1 year ago

Background and Motivation

Microsoft-DotNETCore-SampleProfiler currently samples at a fixed rate of 1 ms, defined in ep-sample-profiler.c. In various situations, it would be beneficial to decrease the rate at which the samples are produced, thus lowering the profiling impact on the runtime.

Proposed Feature

Allow configuring the sampling rate in nanoseconds (_sampling_rate_in_ns) as part of the session creation process, preferably before the sampling starts.

Usage Examples

E.g. profiling in production, minimising the performance impact on the runtime.

Previously, this change was also mentioned in these (differently scoped) issues:

ghost commented 1 year ago

Tagging subscribers to this area: @tommcdon See info in area-owners.md if you want to be subscribed.

Issue Details

## Background and Motivation `Microsoft-DotNETCore-SampleProfiler` currently samples at a fixed rate of 1 ms, defined in [`ep-sample-profiler.c`](https://github.com/dotnet/runtime/blob/844702d736eef2fc456c1e4d89043fab6d054609/src/native/eventpipe/ep-sample-profiler.c#L19). In various situations, it would be beneficial to decrease the rate at which the samples are produced, thus lowering the profiling impact on the runtime. ## Proposed Feature Allow configuring the sampling rate as part of the session creation process, preferably before the sampling starts. ## Usage Examples E.g. profiling in production, minimising the performance impact on the runtime. Previously, this change was also mentioned in these (differently scoped) issues: * https://github.com/dotnet/runtime/issues/45518 * https://github.com/dotnet/diagnostics/issues/1706#issuecomment-728277744

Author:	vaind
Assignees:	-
Labels:	`area-Diagnostics-coreclr`, `untriaged`
Milestone:	-

hoyosjs commented 1 year ago

@tommcdon @davmason I didn't add a milestone, since I don't know if this can get into .NET 8

davmason commented 1 year ago

Hi @vaind,

Thanks for reaching out and filing this issue. I agree that this is a good change and I would like to see it included in dotnet. I am not sure when the work would be scheduled though, and it likely wouldn't make it in for dotnet 8.

This is a good candidate for a motivated external developer to contribute. If you (or anyone reading this) is interested in contributing the steps are pretty straightforward.

We create the sample provider here: https://github.com/dotnet/runtime/blob/507acb66e51ccc8fbe5e95f2a07ec4e3280b330c/src/native/eventpipe/ep-sample-profiler.c#L214.

The callback signature looks like this: https://github.com/dotnet/runtime/blob/507acb66e51ccc8fbe5e95f2a07ec4e3280b330c/src/native/eventpipe/ep-types-forward.h#L180-L187

The filter_data argument is a list of optional key-value pairs the session can specify when enabling the provider. We can add a filter data argument SampleProfilerIntervalMS, if that is provided we can override the default sampling interval.

We would have the potential issue of multiple sessions specifying different overrides, but we can document that whatever the last one that is set is what we will use.

pedrobsaila commented 1 year ago

Hey @davmason I would like to work on it. However I don't find docs that explain how to debug eventpipe. Can you give me some directions on how to do it on windows ? Here is what I tried :

SET DOTNET_EnableEventPipe=1
launched corerun.exe someApp.dll with VS

But VS could not find symbols.

davmason commented 1 year ago

Hi @pedrobsaila,

Thanks for reaching out! EventPipe is built in to the coreclr runtime so you can follow the instructions for building and debugging coreclr:

To debug the runtime itself requires native code debugging, so with VS you have to manually select the debugging engine to be native instead of managed, or you will debug the managed code in the app and not the runtime.

If you debug an app that is built via VS or dotnet build, you will be debugging the publicly available coreclr which is built in release mode and will have a poor debugging experience. For symbols with a publicly release runtime you have to turn on the microsoft public symbol server in the debugging options->symbols in VS.

The better way to debug is to build a debug runtime locally and then publish your test app as "self contained" to a folder. For Windows it would be `dotnet publish -r win-x64 --self-contained". Then you can patch the self contained folder with the output of your build and it will run on your locally built binaries, and debugging will be much better.

bruno-garcia commented 7 months ago

The PR #83635 was closed but there folks seemed to have agreed on a plan:

https://github.com/dotnet/runtime/pull/83635#issuecomment-1518486392

Wondering if this is ending up on a plan anytime soon? Would love to get lower overhead when profiling stuff

dotnet / runtime