多个虚拟机的垃圾收集
Garbage Collection for several VMs
我们有一个应用程序，通常由大约 20 个 JVM 组成，我们向它们分发批处理作业。同一操作系统中的 20 个 JVM 运行。在将批处理作业分派给其中一个之前，很难判断该作业的长度和大小。这可能需要 1 分钟或几个小时。内存消耗同样不同。
到目前为止效果很好，我们总共有 40GB 可用内存，我们将每个 JVM 的最大堆大小设置为 2GB（有时需要 2GB）。由于我们从来没有同时有太多 "big" 批处理作业 运行，所以我们从来没有遇到内存问题。直到我们搬到 Java 8 虚拟机。好像full GC的触发频率比较低。我们的 JVM 大部分处于闲置状态，内存使用率不断上升。当我通过调用 jcmd 触发 GC 时，我可以看到 OldGen 从大约 1GB 下降到 200MB。
我知道拥有 20 个 JVM 并具有最大 2GB 堆 + 堆栈 + 元空间这不是一个好的设置，最大总量将远远超过 40GB 可用内存。但这是我们必须忍受的情况。如果有一种方法可以为多个 JVM 的集群设置最大堆大小，我会感到惊讶。所以我需要想出其他的解决办法。
我正在寻找一些 VM 选项，告诉 VM 定期执行完整的 GC，这很可能会解决我们的问题。但是我找不到执行此操作的 VM 选项。
关于我们如何设置它以避免内存交换的任何建议？
编辑：这是 gc 日志的片段：
2016-04-14T01:02:49.413+0200: 37428.762: [Full GC (Ergonomics) [PSYoungGen: 28612K->0K(629248K)] [ParOldGen: 1268473K->243392K(1309184K)] 1297086K->243392K(1938432K), [Metaspace: 120332K->120320K(1181696K)], 0.3438924 secs] [Times: user=1.69 sys=0.02, real=0.35 secs]
2016-04-14T01:02:52.442+0200: 37431.792: [GC (Allocation Failure) [PSYoungGen: 561664K->67304K(629248K)] 805056K->310696K(1938432K), 0.0315138 secs] [Times: user=0.26 sys=0.00, real=0.03 secs]
2016-04-14T01:02:54.809+0200: 37434.159: [GC (Allocation Failure) [PSYoungGen: 628968K->38733K(623104K)] 872360K->309555K(1932288K), 0.0425780 secs] [Times: user=0.35 sys=0.00, real=0.04 secs]
...
2016-04-14T10:09:03.558+0200: 70202.907: [GC (Allocation Failure) [PSYoungGen: 547152K->41386K(531968K)] 1545772K->1041036K(1841152K), 0.0255883 secs] [Times: user=0.18 sys=0.00, real=0.02 secs]
2016-04-14T10:20:53.634+0200: 70912.984: [GC (Allocation Failure) [PSYoungGen: 531882K->40733K(542720K)] 1531532K->1042107K(1851904K), 0.0306816 secs] [Times: user=0.22 sys=0.02, real=0.03 secs]
2016-04-14T10:23:10.830+0200: 71050.180: [GC (System.gc()) [PSYoungGen: 60415K->37236K(520192K)] 1061790K->1040674K(1829376K), 0.0228505 secs] [Times: user=0.17 sys=0.01, real=0.02 secs]
2016-04-14T10:23:10.853+0200: 71050.203: [Full GC (System.gc()) [PSYoungGen: 37236K->0K(520192K)] [ParOldGen: 1003438K->170089K(1309184K)] 1040674K->170089K(1829376K), [Metaspace: 133559K->129636K(1196032K)], 1.4149811 secs] [Times: user=11.10 sys=0.02, real=1.42 secs]
如果我们每小时进行一次完整的 GC，我想它会解决我们的问题。
您可以尝试 运行 -XX:GCTimeRatio=14 -XX:MaxHeapFreeRatio=30 -XX:MixHeapFreeRatio=20，而不是尝试使用时间触发的 GC。这将告诉收集器保留更少的空间，并通过允许它在 GC 上收集更多 often/spending 更多 CPU 周期来做到这一点。
在当前的 JDK9 构建中，这可以与 -XX:-ShrinkHeapInSteps 进一步结合，让分配的堆大小更接近使用的堆。同样，可能会以牺牲性能为代价。
随机执行 GC 毫无意义。
我会将 GC 添加到批处理的末尾（或之后）。正是由于这一点，可能需要保留最少的内存，使GC更快，并获得最佳收缩。
感谢所有 answers/comments。
我想出的解决方案是大量 answers/comments.
的组合
@Peter Lawrey：
在每个 Batch 运行 之后调用 System.gc() 很有意义，我很惊讶我们没有早点想出这个。它本身并没有帮助减少内存使用量。我们最终会得到一个 1GB 的老年代，它只填充了 200MB 的数据。
@the8472:
GCTimeRatio 似乎没有以任何方式帮助我们。但是我们将 MaxHeapFreeRatio 和 MinHeapFreeRatio 都改为 40。选择较低的值会过多地限制新生代的大小，并且它永远不会增长超过 200MB。
我假设将两个参数设置为相同的值会导致大量内存分配和释放，但是我们在 GC 上花费的时间不到 1% 仍然做得很好。当您执行大量数据库请求时，GC 的性能影响变得可以忽略不计:-)
@西西弗斯：
将 newRatio 设置为 1 有助于让新生代和老年代具有相似的大小。这可能是收益最高的变化。
我们有一个应用程序，通常由大约 20 个 JVM 组成，我们向它们分发批处理作业。同一操作系统中的 20 个 JVM 运行。在将批处理作业分派给其中一个之前，很难判断该作业的长度和大小。这可能需要 1 分钟或几个小时。内存消耗同样不同。
到目前为止效果很好，我们总共有 40GB 可用内存，我们将每个 JVM 的最大堆大小设置为 2GB（有时需要 2GB）。由于我们从来没有同时有太多 "big" 批处理作业 运行，所以我们从来没有遇到内存问题。直到我们搬到 Java 8 虚拟机。好像full GC的触发频率比较低。我们的 JVM 大部分处于闲置状态，内存使用率不断上升。当我通过调用 jcmd 触发 GC 时，我可以看到 OldGen 从大约 1GB 下降到 200MB。
我知道拥有 20 个 JVM 并具有最大 2GB 堆 + 堆栈 + 元空间这不是一个好的设置，最大总量将远远超过 40GB 可用内存。但这是我们必须忍受的情况。如果有一种方法可以为多个 JVM 的集群设置最大堆大小，我会感到惊讶。所以我需要想出其他的解决办法。
我正在寻找一些 VM 选项，告诉 VM 定期执行完整的 GC，这很可能会解决我们的问题。但是我找不到执行此操作的 VM 选项。
关于我们如何设置它以避免内存交换的任何建议？
编辑：这是 gc 日志的片段：
2016-04-14T01:02:49.413+0200: 37428.762: [Full GC (Ergonomics) [PSYoungGen: 28612K->0K(629248K)] [ParOldGen: 1268473K->243392K(1309184K)] 1297086K->243392K(1938432K), [Metaspace: 120332K->120320K(1181696K)], 0.3438924 secs] [Times: user=1.69 sys=0.02, real=0.35 secs]
2016-04-14T01:02:52.442+0200: 37431.792: [GC (Allocation Failure) [PSYoungGen: 561664K->67304K(629248K)] 805056K->310696K(1938432K), 0.0315138 secs] [Times: user=0.26 sys=0.00, real=0.03 secs]
2016-04-14T01:02:54.809+0200: 37434.159: [GC (Allocation Failure) [PSYoungGen: 628968K->38733K(623104K)] 872360K->309555K(1932288K), 0.0425780 secs] [Times: user=0.35 sys=0.00, real=0.04 secs]
...
2016-04-14T10:09:03.558+0200: 70202.907: [GC (Allocation Failure) [PSYoungGen: 547152K->41386K(531968K)] 1545772K->1041036K(1841152K), 0.0255883 secs] [Times: user=0.18 sys=0.00, real=0.02 secs]
2016-04-14T10:20:53.634+0200: 70912.984: [GC (Allocation Failure) [PSYoungGen: 531882K->40733K(542720K)] 1531532K->1042107K(1851904K), 0.0306816 secs] [Times: user=0.22 sys=0.02, real=0.03 secs]
2016-04-14T10:23:10.830+0200: 71050.180: [GC (System.gc()) [PSYoungGen: 60415K->37236K(520192K)] 1061790K->1040674K(1829376K), 0.0228505 secs] [Times: user=0.17 sys=0.01, real=0.02 secs]
2016-04-14T10:23:10.853+0200: 71050.203: [Full GC (System.gc()) [PSYoungGen: 37236K->0K(520192K)] [ParOldGen: 1003438K->170089K(1309184K)] 1040674K->170089K(1829376K), [Metaspace: 133559K->129636K(1196032K)], 1.4149811 secs] [Times: user=11.10 sys=0.02, real=1.42 secs]
如果我们每小时进行一次完整的 GC，我想它会解决我们的问题。
您可以尝试 运行 -XX:GCTimeRatio=14 -XX:MaxHeapFreeRatio=30 -XX:MixHeapFreeRatio=20，而不是尝试使用时间触发的 GC。这将告诉收集器保留更少的空间，并通过允许它在 GC 上收集更多 often/spending 更多 CPU 周期来做到这一点。
在当前的 JDK9 构建中，这可以与 -XX:-ShrinkHeapInSteps 进一步结合，让分配的堆大小更接近使用的堆。同样，可能会以牺牲性能为代价。
随机执行 GC 毫无意义。
我会将 GC 添加到批处理的末尾（或之后）。正是由于这一点，可能需要保留最少的内存，使GC更快，并获得最佳收缩。
感谢所有 answers/comments。 我想出的解决方案是大量 answers/comments.
的组合@Peter Lawrey： 在每个 Batch 运行 之后调用 System.gc() 很有意义，我很惊讶我们没有早点想出这个。它本身并没有帮助减少内存使用量。我们最终会得到一个 1GB 的老年代，它只填充了 200MB 的数据。
@the8472: GCTimeRatio 似乎没有以任何方式帮助我们。但是我们将 MaxHeapFreeRatio 和 MinHeapFreeRatio 都改为 40。选择较低的值会过多地限制新生代的大小，并且它永远不会增长超过 200MB。 我假设将两个参数设置为相同的值会导致大量内存分配和释放，但是我们在 GC 上花费的时间不到 1% 仍然做得很好。当您执行大量数据库请求时，GC 的性能影响变得可以忽略不计:-)
@西西弗斯： 将 newRatio 设置为 1 有助于让新生代和老年代具有相似的大小。这可能是收益最高的变化。