π Automatic Heap Dumps β Feedback wanted! #3885
jamescrosswell
started this conversation in
General
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi everyone,
We introduced experimental support for Automatic Heap Dumps with the version 5.0.0 release of the Sentry SDK for .NET:
Hopefully this makes it easier for you to analyze memory usage issues, detect memory leaks, and debug OutOfMemoryExceptions.
π¦ Prerequisites
The feature currently supports .NET 6 or later on non-Mobile platforms (so it doesn't work on iOS, Android or .NET Framework).
π Feedback
We have a few potential improvements in mind, but we'd love to hear from you first before we go all-in on development. Your feedback will help shape the future of this feature!
β Ease of use β Is the API intuitive?
β Configurability β Do you need more flexibility in defining triggers or debouncing?
β Performance impact β Have you noticed any overhead when enabling heap dumps?
β Compatibility β Have you encountered issues on specific runtimes or configurations?
πΉ Background GC Mode:
According to the docs, the GC.* methods we use to listen for garbage collection event may throw an exception when concurrent garbage collection is enabled.
So far, we haven't been able to reproduce this issueβbut weβd love to hear from users running GC configurations that might be affected.
If this turns out to be a problem, we could adopt an alternative (slightly more complex) design to listen for garbage collection events.
This is especially important as .NET 9 introduces DATAS (Dynamic Adaptation to Application Sizes) as the default GC mode, meaning applications might not always use a single heap.
πΉ Additional triggers
Currently, heap dumps are triggered before an
OutOfMemoryException
occurs.For example, you might configure it to capture a heap dump when memory usage exceeds 90% of total available memory.
Why? Because once an OOM exception is thrown, the process is often too unstable to capture a dump reliably. This is the safest approach when many small allocations are consuming memory over time.
An alternative/additional approach would be to trigger a heap dump when an OutOfMemoryException is actually thrown.
This could be useful in cases where a single large allocation fails (e.g., trying to allocate a massive array). However, in that scenario, a stack trace might be more helpful than a heap dumpβso we didnβt implement this yet.
π‘ Would you prefer the SDK to support heap dumps on specific exceptions?
Let us know if you think this is valuable, and weβll consider adding it!
πΉ Previewing Dumps
Currently you need to download heap dumps from Sentry to view and analyse these. Sentry doesn't have any preview capability for these dump files. If there is strong demand, we could build some basic preview capabilities into the Sentry portal with functionality similar to what you get when running dotnet-gcdump report.
π§ Let Us Know Your Thoughts!
We want to ensure this feature works smoothly across different scenarios before stabilizing the API, so your input is extremely valuable! π
π If you're dealing with memory issues or just curious about heap dumps, please give this feature a try and share your experience below!
Thanks for helping us improve the Sentry SDK for .NET! ππ
Beta Was this translation helpful? Give feedback.
All reactions