并发模式故障，而完全GC

我面临并发模式故障发生，由于我的应用程序响应缓慢。正如我看到许多博客建议降低占用率值并检查，这是并发模式失败的唯一解决方案吗？并发模式故障，而完全GC



    CMS: abort preclean due to time 2015-09-16T23:18:41.306+0200: 3847212.463: [CMS-concurrent-abortable-preclean: 4.934/5.444 secs] [Times: user=5.00 sys=0.01, real=5.45 secs] 
    2015-09-16T23:18:41.311+0200: 3847212.467: [GC[YG occupancy: 266211 K (436928 K)]3847212.467: [Rescan (parallel) , 0.1478990 secs]3847212.615: [weak refs processing, 0.0000180 secs] [1 CMS-remark: 3073996K(4718592K)] 3340208K(5155520K), 0.1480950 secs] [Times: user=1.57 sys=0.01, real=0.15 secs] 
    2015-09-16T23:18:41.460+0200: 3847212.616: [CMS-concurrent-sweep-start] 
    2015-09-16T23:18:44.204+0200: 3847215.360: [CMS-concurrent-sweep: 2.738/2.744 secs] [Times: user=2.76 sys=0.00, real=2.74 secs] 
    2015-09-16T23:18:44.204+0200: 3847215.360: [CMS-concurrent-reset-start] 
    2015-09-16T23:18:44.215+0200: 3847215.371: [CMS-concurrent-reset: 0.010/0.010 secs] [Times: user=0.01 sys=0.00, real=0.02 secs] 
    2015-09-16T23:18:46.221+0200: 3847217.377: [GC [1 CMS-initial-mark: 3073996K(4718592K)] 3347513K(5155520K), 0.3326130 secs] [Times: user=0.33 sys=0.00, real=0.33 secs] 
    2015-09-16T23:18:46.554+0200: 3847217.710: [CMS-concurrent-mark-start] 
    2015-09-16T23:18:46.926+0200: 3847218.083: [Full GC 3847218.083: [CMS2015-09-16T23:18:50.249+0200: 3847221.405: [CMS-concurrent-mark: 3.688/3.695 secs] [Times: user=13.96 sys=0.31, real=3.70 secs] 
    (concurrent mode failure): 3073996K->3011216K(4718592K), 20.7183280 secs] 3348996K->3011216K(5155520K), [CMS Perm : 262143K->40538K(262144K)], 20.7185010 secs] [Times: user=29.87 sys=0.31, real=20.71 secs] 
    2015-09-16T23:27:27.701+0200: 3847738.857: [GC 3847738.858: [ParNew: 349568K->28669K(436928K), 0.0532300 secs] 3360784K->3039885K(5155520K), 0.0534380 secs] [Times: user=0.14 sys=0.00, real=0.05 secs] 
    2015-09-16T23:33:43.242+0200: 3848114.399: [GC 3848114.399: [ParNew: 378237K->14730K(436928K), 0.0492570 secs] 3389453K->3025946K(5155520K), 0.0494510 secs] [Times: user=0.14 sys=0.00, real=0.05 secs] 
    2015-09-16T23:41:35.879+0200: 3848587.035: [GC 3848587.035: [ParNew: 364298K->15247K(436928K), 0.0524070 secs] 3375514K->3026463K(5155520K), 0.0525940 secs] [Times: user=0.15 sys=0.00, real=0.05 secs]

以下是JVM参数设置：



    -server 
    -d64 
    -Xms2048M 
    -Xmx2048M 
    -XX:+DisableExplicitGC 
    -XX:NewSize=512M 
    -XX:MaxNewSize=512M 
    -XX:SurvivorRatio=4 
    -XX:PermSize=256M 
    -XX:MaxPermSize=256M 
    -XX:+UseParNewGC 
    -XX:+UseConcMarkSweepGC 
    -XX:CMSInitiatingOccupancyFraction=65 
    -XX:+UseCMSInitiatingOccupancyOnly 
    -XX:+CMSPermGenSweepingEnabled 
    -XX:MaxTenuringThreshold=30

来源

2015-10-07 ashu

你读过这篇文章：http://stackoverflow.com/questions/2918124/how-to-reduce-java-concurrent-mode-failure-and-excessive-gc – assylias

是的，我已经走了，但仍然是我我无法弄清楚 – ashu

如果你已经经历了这个，你究竟试过了什么？和什么Java版本？多少核心？并且可以提供完整的GC日志（上传/粘贴它们）？ – the8472

既然你有CMSInitiatingOccupancyFraction设置为65％的事实，如果你需要进一步降低它的任何我会感到很惊讶。根据您上传的日志，似乎您的问题的强有力候选人是预清洁阶段。从你的日志，我看到开头的几个消息：

CMS：预洗中止由于时间

这意味着的是，并发预洗阶段（在您的CMS GC基本上没有的东西加速并减少后来停止世界暂停的可能性）正在中止，因此停止世界暂停将比他们需要的更频繁。

因此，您应该考虑增加预清洁阶段的超时时间。这可以通过手动将-XX：CMSMaxAbortablePrecleanTime JVM参数设置为大于5秒来完成。

我对此做了一点研究，并且在"abort preclean due to time"问题上已经有了一个很好的StackOverflow Q/A。还有一个不错的Oracle博客详细介绍了CMS收集器的不同阶段，包括描述what the CMS collector's preclean phase actually does。最后的参考资料详述了syntax of the CMSMaxAbortablePrecleanTime JVM parameter。

在附注中，您有几个适用于您的JVM的调整参数。虽然他们可能有助于表现，但他们也可能不会。实际上，设置多个JVM参数通常会限制JVM为您的自定义应用程序优化垃圾回收的能力。考虑尝试删除一些这些调整参数以改善您的性能问题。

来源

2015-10-19 15:06:26 entpnerd

并发模式故障，而完全GC

回答

相关问题