-
-
Notifications
You must be signed in to change notification settings - Fork 202
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve OutOfMemory insight #3315
Comments
An idea from a Discord discussions - it'd be cool if Sentry could be configured to trigger a memory dump (e.g. if the memory utilisation of the application breached some configured threshold - either a fixed amount of memory or a % of total available memory). We could call dotnet-dump or dotnet-gcdump (that doesn't need to be run with sudo and the dumps can be analyzed in For this to work, Even cooler (not sure how feasible this is) would be if these dumps could be sent to Sentry.io and visualised there. Similar functionality could be implemented by other SDKs, if we could align on a common set of dump formats that Sentry supported. |
Worth noting that one possible cause of OOM exceptions is fragmentation, if you have lots of objects on the LOH (see here). We'll see if we can capture that detail as well. |
We can bundle the executable in the NuGet package and copy to the final app. But for that we need to have the right architecture for the machine. If it's a managed assembly, it'd need the right .NET Runtime version installed on the machine for this to work though.
If there's not enough memory it should compact (solving fragmentation issues) and LOH in modern version of .NET should also compact. The video you linked seems like .NET Framework behavior (which is true that fragmentation led to OOM without any way to recover without a reboot, I encounted that in the past). From https://learn.microsoft.com/en-us/dotnet/standard/garbage-collection/large-object-heap :
Hm I could be wrong about .NET 8's default behavior, unless it's not controlled by this property: From: https://learn.microsoft.com/en-us/dotnet/api/system.runtime.gclargeobjectheapcompactionmode?view=net-8.0#system-runtime-gclargeobjectheapcompactionmode-default
|
Do we think it's a good idea to use the stack trace to fingerprint OOM exceptions? If someone had a tight recursive loop allocating memory, then very likely the stack trace would help point to the culprit. However it's equally possible that the allocation occurs somewhere in the code quite unrelated... it could be thrown literally anywhere memory gets allocated in the program right (just happened to be the straw that broke the camel's back)? Otherwise, we did have that spike to generate gcdumps... I think that would be a more useful diagnostic tool than a stack trace in this case. @bitsandfoxes did we want to prioritise making that production ready? |
This will reqire some alignment with other SDKs, most notably Mobile as to create a coherent experience in the product. The extension to the SDK to support sending gcdumps is an entirely different discussion and I don't think that it would help cutting through the noise. |
Today a OOM exception isn't really actionable. It shows me where it tried to allocated and blew up, which is helpful.
But I dunno how much memory it tried to allocate. How much was available, etc.
(example)
But we have memory information further down in the event detail. It doesn't get displayed very nicely (I created a ticket for that here):
Could we show at the top of the screen a summary:
Had X memory, tried to allocate Y? Or just in general show the memory info closer to the top in a better format. Not all values, but the relevant ones?
The text was updated successfully, but these errors were encountered: