How 'expensive' is it to execute jstack on a running JVM?

Question

I'm considering whipping up a script to

1. run once a minute (or every five minutes)
2. run jstack against a running JVM in production
3. parse the jstack output and tally up things I'm interested in
4. export the results for graphing 24/365 by a centralized Cacti installation on another server

But I've no clue as to how expensive or invasive jstack is on a running JVM. How expensive is it to execute jstack on a running JVM? Am I setting myself up for a world of hurt?

Answer 1

Measure. One of the time variants (/usr/bin/time I believe) has a -p option which allows you to see the cpu resources used:

ravn:~ ravn$ /usr/bin/time -p echo Hello World
Hello World
real         0.32
user         0.00
sys          0.00
ravn:~ ravn$ 

This means that it took 0.32 seconds wall time, using 0.00 seconds of cpu time in user space and 0.00 seconds in kernel space.

Create a test scenario where you have a program running but not doing anything, and try comparing with the usage WITH and WITHOUT a jstack attaching e.g. every second. Then you have hard numbers and can experiment to see what would give a reasonable overhead.

My hunch would be that once every five minutes is neglectible.

Answer 2

I know this answer is late to the party but the expensive part of jstack comes from attaching to the debugger interface not generally generating the stack traces with an important exception (and the heap size does not matter at all):

Arbitrary stack traces can be generated on a safe point only or while the thread is waiting (i.e. outside java scope). If the thread is waiting/outside java scope the stack requesting thread will carry the task by doing the stack walk on its own. However, you might not wish to "interrupt" a thread to walk its own stack, esp while it is holding a lock (or doing some busy wait). Since there is no way to control the safe points - that's a risk need to be considered.

Another option compared to jstack avoiding attaching to the debugging interface: Thread.getAllStackTraces() or using the ThreadMXBean, run it in the process, save to a file and use an external tool to poll that file.

Last note: I love jstack, it's immense on production system.