Closed casperisfine closed 1 year ago
Yeah I think this is worth a shot, certainly makes it a lot less intrusive .
Shouldn't the CLI block though until the dump is ready?
Shouldn't the CLI block though until the dump is ready?
It doesn't right now, but that wouldn't be hard to do. I could call Process.waitpid
in the parent process to block without holding the GVL, that's not a bad idea.
Hum, actually I, the signal handler call Thread.new{ eval(code) }.join
, so I think if we're to block, we'd block one application thread? That's what I'd want to avoid.
That said I think it makes sense to spawn a thread so that we cleanly Process.wait
to reap the child.
Ok, I updated the implementation, let me know what you think.
Hum, I added a little bit more code, because it's true that it's a bit annoying to figure out when it's done dumping.
So now it writes to filename.tmp
, and once done, move it to filename
. This way you don't have to monitor the file size to know when it's done.
Yeah I like this, nice one.
Dumping the heap can lock the VM for a very long time. If you attempt to do this on a webserver process with a timeout it's very likely you'll hit it and the process might get killed before the dump completes.
Worse, if the process was processing some requests or jobs, they might timeout because of it.
Using fork we can make a snapshot of the heap in a very short time (relative to the dump itself) and savely dump without disrupting the original process.
If you are familiar with how Redis does snapshotting, it's very similar.
@SamSaffron what do you think?