More than once at my $dayjob we experienced the need to grab the heap dump or a running process implementing some critical functionality. The problem is that saving of the dump file requires freezing of the process, and if its memory consumption is relatively high (in our case it clocked around 50 GiB), saving of the dump freezes the process for too long to have negative impact (the service processes "real-time" data).
I were thinking of an approach similar to what Redis uses for one of its backup modes on Unix (I'm mainly interested in Linux): it periodically forks itself and the child then saves away the memory it "inherited" from its parent while the parent continues working. This feature takes advantage of the memory CoW mechanism implemented on Linux (and I think on most if not all popular platforms which have fork) to have total memory consumption resonably low, and allows the main process to have relatively brief pauses - required only to fork a child copy and be done with it. Could something like this at leat theoretically be implemented for Go's runtime/debug.WriteHeapDump? Well, in order to not create an XY Problem, I should stress that my end goal would be to have a way to "dump core" of a running Go process with big memory footprint in a way to not freeze the process for too long (under, say, 2 seconds). Being able to somehow collect the "classic" core file (using something what `gcore` does with the help of GDB) would be fine as well, but `gcore` freezes the process as well. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20221010183320.rdm4dyijfcl6hj6n%40carbon.
