tmm1 / rbtrace

like strace, but for ruby code
MIT License
1.71k stars 65 forks source link

Dump heap from a fork #90

Closed casperisfine closed 1 year ago

casperisfine commented 1 year ago

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?

SamSaffron commented 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?

casperisfine commented 1 year ago

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.

casperisfine commented 1 year ago

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.

casperisfine commented 1 year ago

Ok, I updated the implementation, let me know what you think.

casperisfine commented 1 year ago

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.

SamSaffron commented 1 year ago

Yeah I like this, nice one.