You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As described in #2514 and #3870, we could potentially use the dispatch queue's memory pressure information to report watchdog terminations as OOMs. However, we still need to determine how reliable this information is. It's highly likely that it won't work for big increments in memory consumption, for which the watchdog quickly kills the app process, and the app has no time to receive memory pressure information. It could be that this information is useful for OOMs that slowly creep in and eat up the memory. Anyways, if we report OOMs, we need to be sure that there is one; otherwise, it will be confusing to users. Another option is to somehow identify watchdog termination events with high memory pressure in Sentry. Adding breadcrumbs isn't enough because they aren't searchable/filterable in the product.
The text was updated successfully, but these errors were encountered:
Description
As described in #2514 and #3870, we could potentially use the dispatch queue's memory pressure information to report watchdog terminations as OOMs. However, we still need to determine how reliable this information is. It's highly likely that it won't work for big increments in memory consumption, for which the watchdog quickly kills the app process, and the app has no time to receive memory pressure information. It could be that this information is useful for OOMs that slowly creep in and eat up the memory. Anyways, if we report OOMs, we need to be sure that there is one; otherwise, it will be confusing to users. Another option is to somehow identify watchdog termination events with high memory pressure in Sentry. Adding breadcrumbs isn't enough because they aren't searchable/filterable in the product.
The text was updated successfully, but these errors were encountered: