1

关于问题：
在 VM 中的大量 IO 期间，由于停止线程需要更多时间，我们面临 JVM 暂停/缓慢。查看安全点日志时，它显示同步状态花费的时间最多。

安全点日志参考

我们还尝试在超时延迟 (-XX:+SafepointTimeout -XX:SafepointTimeoutDelay=200) 上打印安全点跟踪，以了解哪些线程导致了此问题，但似乎没有任何可疑之处。此外，在为安全点设置超时时，当花费的时间处于“同步”状态时，我们不会检测到超时打印。

关于此安全点跟踪的问题：

  1. 安全点超时如何工作？
  2. 记录线程详细信息后，安全点是否存在并且所有线程都恢复了？
  3. 是否会执行该 VM 操作。如果 vmop 是 GC 会发生什么。

使用 Async-profiler：
尝试使用 async-profiler 进行时间到安全点分析，并注意到 VM 线程在 SafepointSynchronize::begin() 方法上花费了更多时间，而 C2 编译器线程与 VM 线程花费的时间几乎相同。

火焰图

我们怀疑 C2 编译器可能需要时间才能达到安全点。有人可以帮助我们解决这个问题并解释这个安全点时间火焰图吗？提前致谢。

4

1 回答 1

2

SafepointTimeout选项只影响日志记录，即线程不会被中断，VM 操作将正常运行等。

SafepointTimeout并不总是打印超时线程：线程可能在打印发生时已经到达安全点。此外，SafepointTimeout如果整个进程已被操作系统冻结，甚至可能无法检测到超时。

例如，这种“冻结”很多发生

  • 当一个进程在一个 cgroup（容器）中耗尽了它的 cpu 配额时；
  • 当系统的物理内存不足时，会发生直接回收；
  • 由于另一个进程的活动（例如，当atop实用程序检查系统时，我观察到长时间的 JVM 暂停）。

async-profiler确实有一个安全点时间分析选项 ( --ttsp)，尽管正确使用它可能看起来很棘手。它在带有输出的wall分析模式下效果最好。jfr在此配置中，async-profiler 将在安全点同步期间对所有线程（运行和阻塞）进行采样，并使用时间戳记录每个单独的事件。

然后可以使用 JDK Mission Control 分析此类配置文件：选择长暂停前后的时间间隔，并查看此间隔内java线程的堆栈跟踪。

请注意，如果 JVM 进程被“冻结”，async-profiler 线程也不起作用，即在此期间您将看不到收集到的样本。通常，在挂钟分析模式下，对所有线程进行均匀采样。但是，如果您看到“间隙”（在某个时间间隔内错过事件），这显然意味着 JVM 进程尚未收到 CPU 时间。在这种情况下，JVM暂停的原因不在Java应用程序中，而是在操作系统/环境中。

于 2021-04-23T22:39:47.940 回答