多么“昂贵”？是在正在运行的JVM上执行jstack吗？
我正在考虑编写一个脚本，
- 每分钟（或每五分钟）运行一次，
- 针对生产中正在运行的 JVM 运行 jstack
- 解析 jstack 输出并统计我感兴趣的内容，
- 通过 a 导出结果以绘制 24/365在另一台服务器上集中安装 Cacti
但我不知道 jstack 在运行的 JVM 上有多昂贵或侵入性。在正在运行的 JVM 上执行 jstack 的成本有多大？我是否让自己陷入了一个充满伤害的世界？
I'm considering whipping up a script to
- run once a minute (or every five minutes)
- run jstack against a running JVM in production
- parse the jstack output and tally up things I'm interested in
- 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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我知道这个答案已经晚了，但 jstack 的昂贵部分来自于附加到调试器接口，通常不会生成带有重要异常的堆栈跟踪（并且堆大小根本不重要）：
可以生成任意堆栈跟踪仅在安全点上或在线程等待时（即在 java 范围之外）。如果线程正在等待/在 java 范围之外，则堆栈请求线程将通过自行执行堆栈遍历来执行任务。但是，您可能不希望“中断”线程来遍历其自己的堆栈，尤其是在它持有锁（或进行一些繁忙等待）时。由于无法控制安全点，因此需要考虑风险。
与 jstack 相比，另一个选项避免附加到调试接口：Thread.getAllStackTraces() 或使用 ThreadMXBean，在进程中运行它，保存到文件并使用外部工具轮询该文件。
最后一点：我喜欢 jstack，它在生产系统上非常强大。
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.
措施。其中一个
time变体（我相信是/usr/bin/time）有一个 -p 选项，它允许您查看所使用的 cpu 资源：这意味着它花费了 0.32 秒的实际时间，使用了 0.00 秒用户空间中的 cpu 时间和内核空间中的 0.00 秒。
创建一个测试场景，其中有一个程序正在运行但不执行任何操作，并尝试与每秒附加和不附加 jstack 的情况进行比较。然后你就得到了确切的数字，并且可以尝试看看什么会产生合理的开销。
我的直觉是每五分钟一次可以忽略不计。
Measure. One of the
timevariants (/usr/bin/time I believe) has a -p option which allows you to see the cpu resources used: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.
根据线程的数量和堆的大小，jstack 可能非常昂贵。 JStack 旨在用于故障排除，而不是为统计信息收集而设计。最好在检测中使用某种形式或公开 JMX 接口来直接获取您想要的信息，而不是必须解析堆栈跟踪。
Depending on the number of threads and the size of your heap, jstack could possibly be quite expensive. JStack is meant for troubleshooting and wasn't designed for stats gathering. It might be better to use some form on instrumentation or expose a JMX interface to get the information you want directly, rather than have to parse stack traces.