jHiccup分析没有加起来

Question

我有以下jHiccup结果。

显然，图中有几秒钟的巨大峰值。我的应用程序每100毫秒左右输出一次日志。当我阅读我的日志时，我从未看到如此巨大的停顿。此外，我可以通过JVM诊断检查GC中花费的总时间，并说明如下：

Time: 
2013-03-12 01:09:04
Used: 
 1,465,483 kbytes
Committed: 
 2,080,128 kbytes
Max: 
 2,080,128 kbytes
GC time: 
     2 minutes on ParNew (4,329 collections)

8.212 seconds on ConcurrentMarkSweep (72 collections)

总的大GC时间大约是8秒，分布在72个独立的收藏中。根据我的JVM提示，所有这些都低于200毫秒，以限制暂停。

另一方面，我在我的独立网络日志（wireshark）中发现了一个5秒的网络响应时间实例。这意味着暂停存在，但它们不是GC，它们不是阻塞线程或可以在分析器或线程转储中观察到的东西。

我的问题是调试或调整此行为的最佳方法是什么？

此外，我想了解jHiccup如何进行测量。显然，这不是GC暂停时间。

Answer 1

很高兴看到你正在使用jHiccup，它似乎显示出基于现实的打嗝。

jHiccup观察到在JVM上运行的应用程序线程也会看到的“打嗝”。它没有收集原因 - 只是报道了事实。原因可能是导致进程无法运行完全准备好运行的代码的任何原因：GC暂停是一个常见原因，但键盘上的临时^ Z或跨虚拟主机的那些“实时迁移”事件之一将是同样观察..有很多可能的原因，包括操作系统或管理程序级别的调度压力（如果存在），电源管理疯狂，交换等等。我已经看到Linux文件系统压力和透明大页面“后台”碎片整理导致多秒打嗝......

隔离暂停原因的第一步是在jHiccup中使用“-c”选项：它启动一个单独的控制进程（否则是空闲的工作负载）。如果您的应用程序和控制过程都显示大小和时间大致相关的打嗝，您就会知道您正在寻找系统级（而不是过程本地）的原因。如果它们没有关联，你就会知道你的JVM的内部 - 这很可能表明你的JVM暂停了一些大事;无论是GC还是别的东西，比如锁定debiasing或类加载 - 派生 - 去优化，如果时间安全点由于某种原因（和某些原因）很长，那么在某些JVM上可能会花费很长时间[并且通常未报告日志]时间大多数JVM，存在很长时间安全点的可能原因。

jHiccup的测量非常简单，很难出错。整个事情不到650行java代码，所以你可以自己看一下逻辑。 jHiccup的HiccupRecorder线程重复进入睡眠1毫秒，当它唤醒时，它会记录任何时间差异（从睡眠前开始），大于1毫秒作为打嗝。简单的假设是，如果一个准备运行的线程（HiccupRecorder）没有运行5秒钟，同一进程中的其他线程也会看到类似大小的打嗝。

如上所述，jHiccups观察结果似乎在您的独立网络日志中得到了证实，您在那里看到了5秒的响应时间。请注意，并非网络日志都会观察到所有打嗝，因为只有在网络记录器会观察到打嗝。相比之下，没有大于1毫秒的打嗝可以躲避jHiccup，因为即使没有其他活动，它也会尝试每秒唤醒1000次。

这个可能不是GC，但在排除GC之前，我建议您再查看GC日志记录。首先，JVM提示将暂停限制为200毫秒对于所有已知的JVM都是无用的。暂停提示相当于说“请”。此外，除非在选项中包含-XX：+ PrintGCApplicationStoppedTime（并且即使那时也怀疑它们），否则不要相信您的GC日志。除非您包含此标志，否则暂停和部分暂停可能会很长并且不会报告。例如。我已经看到由偶尔长时间运行的计数循环引起的暂停需要15秒才能达到安全点，其中GC仅报告暂停的0.08秒部分，它实际上做了一些工作。还有很多暂停，其原因不被视为“GC”的一部分，因此可以不通过GC记录标记进行报告。

- 吉尔。 [jHiccup的作者]