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
Introduction
This issue is a followup of #23328. The outcome of that issue was the introduction of the v8.writeHeapSnapshot() API.
Next step would be to introduce a way of handling an out of memory situation in JS context.
When running nodejs processes in a low memory environment, every out of memory that occurs is interesting. To figure out why a process went out of memory, a heapdump can help a lot.
Desired solution
There are several possible solutions which would suffice:
add a CLI flag which enables automatic heapdumps on OoM. This might be more feasible, as it doesn't need to be a JS API and thus can be fixed in native code instead of JS. Downside is that it's not flexible.
...
Alternatives
At the moment, we use our own module. This uses native code to hook into the SetOOMErrorHandler handler of V8.
This works although it's not very elegant.
Introduction
This issue is a followup of #23328. The outcome of that issue was the introduction of the
v8.writeHeapSnapshot()API.Next step would be to introduce a way of handling an out of memory situation in JS context.
When running nodejs processes in a low memory environment, every out of memory that occurs is interesting. To figure out why a process went out of memory, a heapdump can help a lot.
Desired solution
There are several possible solutions which would suffice:
process.on('fatal_error'), which kicks in for an OoM event. (see Post-mortem out of memory analysis diagnostics#239 (comment)). The question is if it's feasible to execute JS code after the 'fatal_error' occurred?Alternatives
At the moment, we use our own module. This uses native code to hook into the
SetOOMErrorHandlerhandler of V8.This works although it's not very elegant.