Java CMS垃圾收集花费的时间太长_Java_Garbage Collection_Jvm_Concurrent Mark Sweep

Java CMS垃圾收集花费的时间太长

java jvm

Java CMS垃圾收集花费的时间太长,java,garbage-collection,jvm,concurrent-mark-sweep,Java,Garbage Collection,Jvm,Concurrent Mark Sweep,我们的一位客户遇到了主要的性能问题，这似乎是由于垃圾收集运行时间过长造成的，我不知道该怎么办 Java版本：1.7.067 JVM参数：-Xms10240m-Xmx16386m-XX:NewSize=2048m-XX:MaxPermSize=150m-XX:+UseParNewGC-XX:+UseConcMarkSweepGC-XX:+PrintGCDetails 附加信息该应用程序是web应用程序的服务器后端。服务器连接到一个SQL数据库和多个ERP系统。然后处理这些数据并将其发送到web客

我们的一位客户遇到了主要的性能问题，这似乎是由于垃圾收集运行时间过长造成的，我不知道该怎么办

Java版本：1.7.067 JVM参数：-Xms10240m-Xmx16386m-XX:NewSize=2048m-XX:MaxPermSize=150m-XX:+UseParNewGC-XX:+UseConcMarkSweepGC-XX:+PrintGCDetails

附加信息

该应用程序是web应用程序的服务器后端。服务器连接到一个SQL数据库和多个ERP系统。然后处理这些数据并将其发送到web客户端。该客户在全球范围内有大约50名用户通过这台服务器访问数据

操作系统：Windows Server 2008 R2数据中心+SP1 CPU:Xeon E5-2660 4核+HT 内存：32 GB 到目前为止我都试过了

增加的Xmx和Xms表明Xms应该相同或至少接近Xmx以获得最佳性能修正了年轻一代比例1、2、3的大小增加渗透率尝试了不同的GC变体下面是gc日志的一些部分。您可以清楚地看到gc持续时间随着时间的推移而增加，峰值约为！！！17秒

是什么导致了这些问题？是否有需要修补的JVM参数

更新日期：2016年3月25日

运行VisualVM后，我似乎发现了一个问题：年轻一代现在设定为4GB——伊甸园和幸存者之间的比例似乎相差很远。。。伊甸园=3,5 GB，而幸存者=0,5 GB 由于有很多新对象一直在生成，这是我需要进一步研究的一件事，因此Eden的填充空间超过了0,5 GB，更像是1到2 GB。幸存者无法持有它，因此会触发一个主要GC

出现的新问题：

我的假设错了吗？我认为我的下一步应该是手动设置幸存者比率。根据我的情况有什么建议吗？我需要禁用AdaptiveSizePolicy吗-XX:-使用自适应策略为什么GC日志将原因显示为System.GC，而在反编译所有类并检查的代码中肯定没有触发手动GC： 2016-03-25T04:59:55.726+0100:14992.418:[完整的GC系统。gc2016-03-25T04:59:55.726+0100:14992.418:[CMS:265708K->265749K6291456K，1.1520720秒]507160K->265749K10066368K[CMS Perm:54875K->54875K91504K]，1.1523255秒][次：用户=1.14系统=0.00，实际=1.14秒]

旧日志/24.03.2016

启动后的前几个日志：

12.434: [GC12.434: [ParNew: 1677824K->100069K(1887488K), 0.0983359 secs] 1677824K->100069K(10276096K), 0.0985257 secs] [Times: user=0.31 sys=0.02, real=0.11 secs] 
16.293: [GC16.293: [ParNew: 1777893K->209664K(1887488K), 0.1933143 secs] 1777893K->212290K(10276096K), 0.1934443 secs] [Times: user=0.50 sys=0.02, real=0.19 secs] 
19.994: [Full GC19.994: [CMS: 2626K->172662K(8388608K), 0.6312313 secs] 1521173K->172662K(10276096K), [CMS Perm : 24831K->24825K(24896K)], 0.6314259 secs] [Times: user=0.70 sys=0.06, real=0.64 secs] 
261.411: [Full GC261.411: [CMS: 172662K->27686K(8388608K), 0.2232379 secs] 876118K->27686K(10276096K), [CMS Perm : 30913K->30911K(41376K)], 0.2234464 secs] [Times: user=0.22 sys=0.00, real=0.22 secs] 
441.716: [Full GC441.716: [CMS: 27686K->24604K(8388608K), 0.1768511 secs] 500368K->24604K(10276096K), [CMS Perm : 30937K->30936K(51520K)], 0.1770344 secs] [Times: user=0.17 sys=0.00, real=0.17 secs]

一段时间后：

20235.044: [Full GC20235.044: [CMS: 195484K->248016K(8388608K), 1.0221468 secs] 798601K->248016K(10276096K), [CMS Perm : 52564K->52564K(87480K)], 1.0223571 secs] [Times: user=1.00 sys=0.02, real=1.01 secs] 
20431.860: [Full GC20431.860: [CMS: 248016K->404539K(8388608K), 1.6120188 secs] 1385622K->404539K(10276096K), [CMS Perm : 54537K->54536K(87672K)], 1.6122663 secs] [Times: user=1.58 sys=0.03, real=1.61 secs] 
20655.867: [Full GC20655.867: [CMS: 404539K->323692K(8388608K), 1.4389098 secs] 958490K->323692K(10276096K), [CMS Perm : 54655K->54652K(90896K)], 1.4391006 secs] [Times: user=1.43 sys=0.00, real=1.43 secs] 
20956.441: [Full GC20956.441: [CMS: 323692K->378663K(8388608K), 1.4717112 secs] 1233969K->378663K(10276096K), [CMS Perm : 54713K->54713K(91092K)], 1.4719180 secs] [Times: user=1.47 sys=0.00, real=1.47 secs] 
21149.053: [Full GC21149.053: [CMS: 378663K->284427K(8388608K), 1.1860728 secs] 717555K->284427K(10276096K), [CMS Perm : 54828K->54828K(91284K)], 1.1862890 secs] [Times: user=1.19 sys=0.00, real=1.19 secs] 
21438.332: [Full GC21438.332: [CMS: 284427K->519857K(8388608K), 2.0659280 secs] 1676708K->519857K(10276096K), [CMS Perm : 62993K->62984K(91476K)], 2.0662088 secs] [Times: user=2.03 sys=0.03, real=2.06 secs] 
21738.902: [Full GC21738.903: [CMS: 519857K->470206K(8388608K), 1.9628709 secs] 1590878K->470206K(10276096K), [CMS Perm : 63230K->63229K(104976K)], 1.9631042 secs] [Times: user=1.95 sys=0.00, real=1.95 secs] 
21922.221: [Full GC21922.221: [CMS: 470206K->448817K(8388608K), 1.7216487 secs] 1127397K->448817K(10276096K), [CMS Perm : 63269K->63269K(105384K)], 1.7218965 secs] [Times: user=1.72 sys=0.00, real=1.72 secs] 
22161.837: [Full GC22161.837: [CMS: 448817K->435548K(8388608K), 1.7168703 secs] 943145K->435548K(10276096K), [CMS Perm : 63298K->63298K(105576K)], 1.7170921 secs] [Times: user=1.72 sys=0.00, real=1.72 secs] 
22402.100: [Full GC22402.100: [CMS: 435548K->613005K(8388608K), 2.3503697 secs] 1841133K->613005K(10276096K), [CMS Perm : 65977K->65976K(105576K)], 2.3506446 secs] [Times: user=2.29 sys=0.05, real=2.34 secs] 
22642.893: [Full GC22642.893: [CMS: 613005K->621214K(8388608K), 2.3825301 secs] 1710749K->621214K(10276096K), [CMS Perm : 66925K->66924K(109964K)], 2.3827835 secs] [Times: user=2.37 sys=0.00, real=2.37 secs] 
22883.148: [Full GC22883.148: [CMS: 621214K->600821K(8388608K), 2.4086658 secs] 1523224K->600821K(10276096K), [CMS Perm : 67550K->67550K(111544K)], 2.4089147 secs] [Times: user=2.40 sys=0.00, real=2.40 secs]

在gc持续时间的峰值：

51603.282: [Full GC51603.282: [CMS: 4940385K->4859068K(8388608K), 16.6679541 secs] 5987385K->4859068K(10276096K), [CMS Perm : 114750K->114750K(153600K)], 16.6684484 secs] [Times: user=16.66 sys=0.00, real=16.66 secs] 
51813.482: [Full GC51813.482: [CMS: 4859068K->4900085K(8388608K), 16.4928686 secs] 6116576K->4900085K(10276096K), [CMS Perm : 114750K->114750K(153600K)], 16.4933047 secs] [Times: user=16.49 sys=0.00, real=16.49 secs] 
52026.148: [Full GC52026.148: [CMS: 4900085K->4896483K(8388608K), 16.8907197 secs] 6090675K->4896483K(10276096K), [CMS Perm : 114755K->114755K(153600K)], 16.8911947 secs] [Times: user=16.88 sys=0.00, real=16.89 secs] 
52223.160: [Full GC52223.160: [CMS: 4896483K->5031826K(8388608K), 17.1507980 secs] 6559062K->5031826K(10276096K), [CMS Perm : 114763K->114763K(153600K)], 17.1513112 secs] [Times: user=17.16 sys=0.00, real=17.16 secs] 
52425.802: [Full GC52425.802: [CMS: 5031826K->5016422K(8388608K), 17.8492606 secs] 6444936K->5016422K(10276096K), [CMS Perm : 114811K->114811K(153600K)], 17.8497294 secs] [Times: user=17.85 sys=0.00, real=17.85 secs] 
52628.857: [Full GC52628.858: [CMS: 5016422K->5077701K(8388608K), 17.9003775 secs] 6606932K->5077701K(10276096K), [CMS Perm : 114812K->114812K(153600K)], 17.9027559 secs] [Times: user=17.88 sys=0.02, real=17.89 secs] 
52747.442: [GC52747.443: [ParNew: 1677824K->209664K(1887488K), 1.3771078 secs] 6755525K->5530527K(10350324K), 1.3774630 secs] [Times: user=1.64 sys=0.08, real=1.37 secs] 
52833.644: [Full GC52833.644: [CMS: 5320863K->4956574K(8462836K), 17.7157636 secs] 6575478K->4956574K(10350324K), [CMS Perm : 114826K->114826K(153600K)], 17.7162266 secs] [Times: user=17.74 sys=0.00, real=17.72 secs] 
53058.481: [Full GC53058.482: [CMS: 4956574K->5002967K(8462836K), 17.9367047 secs] 6626713K->5002967K(10350324K), [CMS Perm : 114835K->114835K(153600K)], 17.9371138 secs] [Times: user=17.92 sys=0.00, real=17.92 secs]

完整日志：

内存泄漏可能导致暂停。当系统预热后，您可以拍摄堆转储的快照，并使用类似于的工具对其进行分析。您可以使用jvisualvm连接到正在运行的进程，并尝试采样/分析内存使用情况。最有效的修复方法是优化算法

是什么导致了这些问题

Add-XX:+printgcause查看触发完整GC的原因。

当CMS失败时，它会返回到一个单线程收集器，您可以通过real==您希望避免的用户时间来查看它

我怀疑您的幸存者空间不够大，以至于当清理伊甸园空间时，幸存者中没有足够的空间，这会触发一个完整的GC，单线程。

没有关于应用程序架构的任何细节，我认为任何人都无法猜到。添加了更多细节；让我烦恼的是，即使在启动softwareShow top或vmstat info后不久，也会发生完全GC。你需要知道这需要计算机资源。可能是iowait，例如抱歉，hacker13ua，但我不明白。top或vmstat信息是什么意思？这是一个Java控制台应用程序，在windows 24小时运行，并在午夜重新启动。堆大小似乎太大，无法满足其原始需求。8~10g的xmx和2.5g~4g的xmn可能更适合。谢谢，我为visualVM设置了一切。明天我将进行一些堆转储，并尝试找出是否存在内存泄漏。我仍然不明白的是为什么几乎所有的GCs都是全GCs。。。即使在jvm启动后不久，堆已满，收集器也无法释放足够的空间。由于堆中仍然没有足够的空间，因此会触发FullGC。一次又一次…是的，我理解小调/大调GC的概念。但堆甚至还没有满——16g从未使用过。尤其是在启动软件之后……现在我已经运行了VisualVM：如何在新实例中获得堆转储之间的差异。我只能看到不同的实例计数/大小。但这并没有多大帮助——也就是说，5000个HashMap条目之间的差异很有趣，但我需要知道它们是什么，因为无法搜索所有条目manually@Gishan，拿一个heapdump，试着用内存分析器分析它。谢谢，我也添加了这个。明天我将使用生成的日志进行更新。