Java 执行GC时，是什么导致safepoint应用程序线程暂停期间vmop时间增加

我正在Linux服务器2.6.32-504.el6.x86_64（RHEL）上运行Java7（Java HotSpot（TM）64位服务器VM（build 24.76-b04，混合模式）；启用的GC交换机很少，如下所示

问题似乎是暂停应用程序线程（>3Sec）时时间显著增加；根据safepointstatistics，它似乎与vmop操作有关

我观察到，由于GC或任何分配失败，没有太多开销，在程序执行期间只发生了少量的收集。下面粘贴的GC日志包含来自GC的引用，就在应用程序线程暂停时间超过3秒之前，GC显示了实际的延迟

问题

此时间接收器是否可能与服务器冻结或没有响应有关，这是基于实时花费3.02秒的假设，并且没有显示由于GC而产生的任何开销。（[Times:user=0.02 sys=0.00，real=3.02秒]）

是否有任何实用程序可用于监控系统响应性，或者是否有任何推荐的算法可用于测量服务器响应性

什么导致vmop时间增加

JVM在启动垃圾收集时是否执行任何磁盘IO；换句话说，在安全点暂停应用程序线程之前，JVM是否执行任何磁盘IO；或者在GC期间具有高磁盘IO活动的系统是否会导致暂停应用程序线程的延迟

服务器配置：

请注意，此服务器上运行多个应用程序，这不是所述应用程序的专用服务器

已启用GC选项：

以前的GC（未显示任何问题）

GC，其中实时>3秒

如果您对此有任何意见，我们将不胜感激。如果您需要更多详细信息，请告诉我

停止线程的时间通常是应用程序没有响应的时间。因此，是的，我希望看到应用程序挂起

你试过jhiccup吗

（和4.）我想到了一件事：。它描述了GC期间写入hsperf数据的暂停（“真正的”暂停）。还有一个复制案例，您可以在您的机器上尝试

---

您应该使用

-XX:+PrintGCDetails

打印GC阶段分解，这可能会提供进一步的见解。没错，问题不在GC中，因为它不占用CPU时间：

user=0.02 sys=0.00

。应用程序似乎由于外部活动而冻结。请密切注意磁盘I/O、交换或其他繁忙的操作系统进程（

top

，

top

，

iotop

等可能会有所帮助）我可以看到有一些磁盘IO，但不确定磁盘IO如何阻止GC暂停应用程序线程。GC在启动收集时是否执行任何磁盘IO。可能是GC取消了脏内存映射缓冲区的映射？但在进一步推测之前，您应该先确定另一个进程是否正在窃取资源（CPU时间|内存->强制交换|饱和IO带宽）或者如果java进程负责自己的暂停。运行top，平均负载是多少？有多少内核？交换使用率是多少？

model name: Intel(R) Xeon(R) CPU X5365  @ 3.00GHz / 8 Core

             total       used       free     shared    buffers     cached
Mem:      24602892   22515868    2087024        244     165796   10801380
-/+ buffers/cache:   11548692   13054200'

-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/opt/swxsmf_fep/working/gk-gc-CMS.log -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCApplicationStoppedTime\
 -XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1 -XX:+PrintGCApplicationConcurrentTime

2015-04-08T19:05:24.622+0100: 522569.387: Application time: 16.4710580 seconds
2015-04-08T19:05:24.622+0100: 522569.387: [GC2015-04-08T19:05:24.622+0100: 522569.387: [ParNew: 102798K->79K(115456K), 0.0018020 secs] 105218K->2499K(371776K), 0.0019090 secs] [Times: user=0.02 sys=0.00, rea
l=0.00 secs]
2015-04-08T19:05:24.624+0100: 522569.389: Total time for which application threads were stopped: 0.0021910 seconds

vmop [threads: total initially_running wait_to_block]  [time: spin block sync cleanup vmop] page_trap_count
522588.500: GenCollectForAllocation          [      22          0              0    ]      [     0     0     0     0  3019    ]  0

    2015-04-08T19:05:43.747+0100: 522588.512: Application time: 19.1232430 seconds
    2015-04-08T19:05:43.748+0100: 522588.512: [GC2015-04-08T19:05:46.765+0100: 522591.530: [ParNew: 102735K->77K(115456K), 0.0017640 secs] 105155K->2497K(371776K), 3.0195450 secs] [Times: user=0.02 sys=0.00, real=3.02 secs]
2015-04-08T19:05:46.767+0100: 522591.532: Total time for which application threads were stopped: 3.0198060 seconds