Java堆大的NewSize使得进程长时间不受阻碍
我有Java应用程序，这使得一些工作具有特定的内存使用情况。 我注意到，当我开始为年轻一代的将近80％的堆设置启动应用程序时，我的应用程序的工作速度比默认的1：2设置快得多。 特别是，我正在启动jvm：
java -XX:NewSize=10G -XX:+UseParallelOldGC -server -Xmx12G -Xms12G
服务器至少有14Gb的可用物理内存，所以它应该足够我认为，对于java堆和“其他”空间。
现在事情就是这样发生的：
25.289: [GC [PSYoungGen: 7872317K->1058813K(9175040K)] 7872533K->1059029K(11272192K), 0.1876420 secs] [Times: user=1.92 sys=1.01, real=0.18 secs]
28.918: [GC [PSYoungGen: 8923133K->1091124K(9175040K)] 8923349K->1091340K(11272192K), 0.2206940 secs] [Times: user=1.92 sys=1.70, real=0.22 secs]
32.946: [GC [PSYoungGen: 8955444K->1060567K(9175040K)] 8955660K->1060783K(11272192K), 0.1804050 secs] [Times: user=2.86 sys=0.01, real=0.18 secs]
37.166: [GC [PSYoungGen: 8924887K->1080085K(8329344K)] 8925103K->1080301K(10426496K), 0.1891370 secs] [Times: user=3.08 sys=0.01, real=0.19 secs]
41.326: [GC [PSYoungGen: 8098709K->1088209K(8106880K)] 8098925K->1088425K(10204032K), 0.2284920 secs] [Times: user=3.49 sys=0.04, real=0.23 secs]
45.779: [GC [PSYoungGen: 8106833K->59784K(8672768K)] 8107049K->1039790K(10769920K), 0.2195770 secs] [Times: user=2.02 sys=1.91, real=0.22 secs]
49.963: [GC [PSYoungGen: 6953352K->75043K(8689664K)] 7933358K->1062837K(10786816K), 0.0384440 secs] [Times: user=0.63 sys=0.01, real=0.04 secs]
54.171: [GC [PSYoungGen: 6968611K->140387K(8737984K)] 7956405K->1129497K(10835136K), 0.0715690 secs] [Times: user=1.12 sys=0.00, real=0.07 secs]
58.455: [GC [PSYoungGen: 7093923K->194024K(8701312K)] 8083033K->1205300K(10798464K), 0.0952730 secs] [Times: user=1.66 sys=0.02, real=0.10 secs]
62.825: [GC [PSYoungGen: 7147560K->122912K(8840256K)] 8158836K->1298466K(10937408K), 0.1671770 secs] [Times: user=2.89 sys=0.10, real=0.16 secs]
67.302: [GC [PSYoungGen: 7270304K->117888K(8792896K)] 8445858K->1377169K(10890048K), 0.1156200 secs] [Times: user=1.98 sys=0.05, real=0.12 secs]
71.785: [GC [PSYoungGen: 7265280K->119002K(8950720K)] 8524561K->1464556K(11047872K), 0.1152940 secs] [Times: user=1.97 sys=0.09, real=0.11 secs]
76.448: [GC [PSYoungGen: 7477018K->206455K(8893056K)] 8822572K->1642652K(10990208K), 0.1607870 secs] [Times: user=2.63 sys=0.06, real=0.16 secs]
81.051: [GC [PSYoungGen: 7564471K->114350K(9084608K)] 9000668K->1649307K(11181760K), 0.1145730 secs] [Times: user=1.89 sys=0.16, real=0.12 secs]
86.020: [GC [PSYoungGen: 7739630K->125895K(9026432K)] 9274587K->1743248K(11123584K), 0.1125030 secs] [Times: user=1.95 sys=0.06, real=0.11 secs]
91.007: [GC [PSYoungGen: 7751175K->202320K(9221952K)] 9368528K->1905769K(11319104K), 0.1523180 secs] [Times: user=2.58 sys=0.06, real=0.15 secs]
95.817: [GC [PSYoungGen: 8085136K->327488K(9146624K)] 9788585K->2203753K(11243776K), 0.2542190 secs] [Times: user=4.44 sys=0.10, real=0.25 secs]
96.071: [Full GC [PSYoungGen: 327488K->0K(9146624K)] [ParOldGen: 1876265K->1032314K(2097152K)] 2203753K->1032314K(11243776K) [PSPermGen: 27528K->21277K(48128K)], 1.4351920 secs] [Times: user=5.12 sys=0.36, real=1.44 secs]
正如你所看到的，一切都很好，完整的GC工作正常。 但是接下来发生的GC（不全）显着增加了进程的内存使用量，并且服务器正在使用交换。
102.741: [GC-- [PSYoungGen: 7882816K->7882816K(9146624K)] 8915130K->9979962K(11243776K), 133.4433280 secs] [Times: user=69.73 sys=602.83, real=133.46 secs]
236.191: [Full GC [PSYoungGen: 7882816K->0K(9146624K)] [ParOldGen: 2097146K->1069237K(2097152K)] 9979962K->1069237K(11243776K) [PSPermGen: 21277K->21251K(48192K)], 6.9285350 secs] [Times: user=12.75 sys=0.23, real=6.93 secs]
问题是 - 为什么？ 据我所知，完整的gc是gc处理中最痛苦的一点。 那么为什么应用程序在完整gc成功完成后停止？
由于系统时间非常高（远高于用户时间），这表明操作系统正在发生一些事情。 你说你有足够的内存，但是如果只有一小部分JVM被交换到磁盘上，它可以杀死GC时间。
我建议减少堆的总大小，以确保你有更多的空闲内存的操作系统/磁盘缓存/其他程序。
为了进一步改进您的应用程序，我会使用内存分析器（很可能您需要使用商业版，eval许可证才会这样做）您似乎正在生成每秒1.5 GB的垃圾，这是令人难以置信的数量。 如果您可以将其削减到每秒几百MB，它应该显着提高您的性能（以及减少延迟）
BTW： -server应该是任何64位机器的默认设置。
我已经工作了几年，需要一个堆大小和内存流失类似于您的应用程序（20 GB堆，1 GB + /秒流失）。 正如@Peter Lawrey所说，如果你可以减少内存消耗或者流失，你会出来（仅供参考 - 我与YourKit分析器运气不错，与公司没有关系，但是我的经验是YMMV）。）
但是，如果实际上无法减少堆使用量或流失率，我建议您考虑进行一些更多的GC调整。 你显然已经做了一些; 这里有一些对我们有用的东西：
-XX:+PrintGCDetails -XX:+PrintGCDateStamps - 有时在GC日志中有真正的日期很好）
-XX:+UseConcMarkSweepGC - 并发旧式GC消耗更多的CPU，但提供更短的暂停。 对于我们的应用程序，这是我们的偏好，听起来像它也可能是你的。
您也可以将-XX:ParallelGCThreads=<threads>设置为适合您的硬件的某些东西（我们在12核机器上使用了6个，但我不知道我们已经优化过）。
上一篇: Large NewSize of java heap make process unresposive for long time