Java 低暂停采集器-并发模式故障

我们在prod中的一个应用程序遇到问题

VM的配置如下所示

-XX:MaxPermSize=300M-Xms2560M-Xmx2560M-Xloggc:/app/log/gc-admin-20120619-123754.log-verbose:gc-XX:+printgtimestamps-XX:+printgDetails-XX:+UseConcMarkSweepGC-XX:cmSinitiatingOccinecyFraction=80-XX:+DisableExplicitGC-XX:CMSMaxAbortablePrecleanTime=8000

我遗漏了两个选项，将应用于 XX:PermSize-应与MaxPermSize相同（推荐） 仅当使用CMSinitiatingOccupencyFraction时才使用CMSinitingOccupency，否则您指定的值不会保持不变

然而，随着这些变化，我不太相信它会解决我的问题

我看到并发模式失败，但当失败发生时，停止世界收集需要一段时间。现在我有点困惑为什么

这是一些样品

168427.476:[GC[1厘米初始标记：2135988K（2578880K）]2141041K（2617216K），3.1029210秒][时间：用户=0.02系统=0.01，实数=3.10秒] 168430.596:[CMS并发标记开始] 168441.309:[gc168441.309:[ParNew:36520K->36520K（38336K），0.0000210秒]168441.309:[CMS168747.453:[CMS并发标记：309.313/316.857秒][次：user=5.75 sys=2.89，real=316.81秒] （并发模式故障）：2561882K->1310927K（2578880K），767.0309740秒]2598402K->1310927K（2617216K），[CMS Perm:96774K->96171K（158792K）]，767.0379030秒][次：用户=3.87系统=5.06，实际=766.92秒]

关于整个STW集合，让我担心的是计时766.92秒，但CPU时间只有“user=3.87 sys=5.06”，所以在剩下的时间里这里发生了什么？？这就是我困惑的地方，我无法想象停止应用程序中的所有线程需要那么长时间！！可能是打人

169545.325:[GC[1厘米初始标记：2141069K（2578880K）]2166025K（2617216K），0.0530140秒][次：用户=0.05系统=0.00，实际=0.06秒] 169545.379:[CMS并发标记开始] 169558.635:[CMS并发标记：10.407/13.256秒][次数：用户=7.58秒系统=0.53，实数=13.25秒] 169558.635:[CMS并发预清洁启动] 169558.684:[CMS并发预清洗：0.048/0.048秒][次数：用户=0.01系统=0.00，实际=0.05秒] 169558.684:[CMS并发中止预清洁启动] 169560.544:[GC 169560.544:[ParNew169560.605:[CMS并发可中止预清理：0.210/1.921秒][次数：用户=0.93系统=0.05，实数=1.92秒] 169560.846:[GC[YG入住率：1906K（38336K）]169560.846:[重新扫描（并行），0.0046910秒]169560.851:[弱参考处理，0.0000990秒][1 CMS备注：2350428K（2578880K）]2352335K（2617216K），0.0048570秒][次数：用户=0.01系统=0.00，实际=0.01秒] 169560.853:[CMS并发扫描开始] 169568.204:[CMS并发扫描：7.351/7.351秒][次数：用户=0.91系统=0.09，实际=7.34秒] 169568.204:[CMS并发重置启动] 169568.211:[CMS并发重置：0.007/0.007秒][次数：用户=0.01系统=0.00，实值=0.01秒]

这个没有问题

252247.318:[GC[1厘米初始标记：2069401K（2578880K）]2075094K（2617216K），1.5311840秒][次：用户=0.01系统=0.00，实际=1.53秒] 252248.849:[CMS并发标记开始] 252350.336:[GC 252350.336:[ParNew:20984K->4222K（38336K），12.2251190秒]252362.561:[CMS252520.780:[CMS并发标记：161.376/271.922秒][次：user=12.56 sys=1.72，real=271.89秒] （并发模式故障）：2232372K->1061586K（2578880K），407.2310250秒]2240205K->1061586K（2617216K），[CMS Perm:97525K->97381K（160480K）]，419.4586450秒][次：用户=4.23系统=2.99，实值=419.39秒]

然后是另一个巨大的“Times:user=4.23 sys=2.99，real=419.39秒”。CPU时间是次要的“user=4.23 sys=2.99”，但总时间是“419.39”。什么会导致VM挂起这么长时间？2.5g最好在10秒以下的STW集合中收集

我将降低CMSInitiatingOccupancyFraction的门槛，但我不认为这样的收集时间会有帮助！！有些收集会顺利进行，有些不会，但正如我所说，当世界完全停止时，正是这个时间让我担心

我读过

我们正在使用jdk6

---

以前有人经历过类似的事情吗？

您的应用程序是否在虚拟机上运行

一种解释可能是，您的主机过载或交换，这会阻止VM工作并看到发生了什么。

永久生成（

PermSize

）用于保存VM本身的反射对象，例如类对象和方法对象。这些反射对象直接分配到永久生成中，并且其大小与其他生成独立。通常，可以忽略此生成的大小，因为默认大小足够。但是，加载多个cl的程序驴可能需要更大的永久世代

默认情况下，

MaxPermSize

对于-client将为32mb，对于-server将为64mb。但是，如果不同时设置

PermSize

和

MaxPermSize

，则除非需要，否则整个堆不会增加。例如，当同时设置

PermSize

和

MaxPermSize

时，额外的堆空间将得到全部空间当它启动时被分配，并将保持分配状态

尝试调整两个VM参数，这可能会解决您的问题

-XX:PermSize=300m -XX:MaxPermSize=300m

---

正如您所观察到的，当并发模式失败时，会返回以停止world collection。我的理解是，这可以使用标记扫描紧凑收集器而不是更高效的复制收集器来完成

这并不能完全解释为什么收集需要如此长的时间。然而，虚拟机抖动是一个合理的理论，您的证据支持这一点……但您需要获得一些操作系统级别的虚拟机交换/分页速率测量值才能确定。（如果JVM将导致抖动，则在堆被清除时，在完全垃圾收集期间，抖动最为严重