java堆的大新闻大小使进程长时间不可定位

我有一个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的垃圾，这是一个难以置信的数量。如果您可以将其降低到每秒几百MBs，那么应该可以显著提高性能（同时减少延迟）

---

顺便说一句：

-server

应该是任何64位机器上的默认值。

我已经使用了几年的应用程序，它需要与您类似的堆大小和内存波动（20 GB堆，1 GB+/秒的波动）。正如@Peter Lawrey所说的，如果你能减少总内存消耗或流失量，你就会脱颖而出（仅供参考-我很幸运使用了YourKit profiler。与该公司没有关联，但我的经验很好。YMMV）

<>但是，如果你实际上不能减少堆的使用或搅动，我建议你考虑更多的GC调整。你显然做了一些；以下是一些对我们有用的东西：

• 减少新的gen大小（您当前正在分配10 GB，并且几乎每几秒钟收集一次。您最好分配1-2 GB并更频繁地收集。这将允许您减少总堆大小，并可能避免交换

-XX:+PrintGCDetails-XX:+PrintGCDateStamps

-有时候在GC日志中有真实的日期很好）

-XX:+UseConcMarkSweepGC

-并发旧代GC消耗更多CPU，但提供更短的暂停时间。对于我们的应用程序，这是我们的首选，听起来可能也是您的首选

您还可以将

-XX:ParallelGCThreads=

设置为适合您的硬件的合理值（我们在12核机器上使用6，但我不知道我们是否已将其优化）