Spike: memory dumps for high memory consumption

[jamescrosswell]

POC relates to #3315

Currently all the code is in one of the samples, but we could battle harden this and initialise it from some SentryOptions if we agreed this makes sense for the SDK.

Important Note

For the dump to work, dotnet-gcdump needs to be installed globally:

dotnet tool install --global dotnet-gcdump

Analysing the Dump File

A couple of different options:

1. dotnet-gcdump report
2. Open the dump file with Perfview or Visual Studio... provides richer functionality but is only available on Windows.
3. dotnet-heapview

See Stefan Geiger's blog for a bit of info on the first two options.

[jamescrosswell]

This issue here is another really good use case for this capability. He has an issue every 90 minutes but can't easily get a memory dump because he's running in Azure:

• Increased CPU and memory overhead while profiling #3199 (comment)

I can't get a memory dump because Azure reasons. I will now redeploy with SignalR disabled and see what happens.

[bruno-garcia]

@jamescrosswell if we bundled this binary in the Sentry SDK, could we shell out and invoke it from within the proc?

[jamescrosswell]

@jamescrosswell if we bundled this binary in the Sentry SDK, could we shell out and invoke it from within the proc?

Yes, indeed. The only thing it needs is for dotnet-gcdump to be installed... I think implicitly that means it won't work on Mobile (since you wouldn't have dotnet installed on Mobile) but could be a great diagnostic tool for server apps.

[bruno-garcia]

@jamescrosswell if we bundled this binary in the Sentry SDK, could we shell out and invoke it from within the proc?

Yes, indeed. The only thing it needs is for dotnet-gcdump to be installed... I think implicitly that means it won't work on Mobile (since you wouldn't have dotnet installed on Mobile) but could be a great diagnostic tool for server apps.

That's what I meant by bundling it. If we add the exe to our package, and with msbuild copy to output when app is published. We'd have it there and know its path. Would that work?

[jamescrosswell]

That's what I meant by bundling it. If we add the exe to our package, and with msbuild copy to output when app is published. We'd have it there and know its path. Would that work?

Ah, I see... yes it looks like that should be possible. The dotnet-gcdump package doesn't have any dependencies other than the net6.0 runtime (or higher).

People targeting net fx/standard would need to ensure they installed the net6.0 runtime then, but it would work ootb of everyone else.

[jamescrosswell]

Replaced by:

• Automatically capture heap dumps #3667