【发布时间】:2018-01-25 07:40:49
【问题描述】:
我们最近一直在测试 G1 垃圾收集器,配置如下:
-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseG1GC -XX:MaxGCPauseMillis=1250 -XX:+PrintTenuringDistribution -Xloggc:${logdir}/gc-$(date +%Y_% m_%d-%H_%M).log -XX:+UseStringDeduplication -XX:+PrintStringDeduplicationStatistics -XX:+PrintPromotionFailure -XX:+PrintAdaptiveSizePolicy -XX:+PrintHeapAtGC -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX: GCLogFileSize=100M -XX:+UnlockExperimentalVMOptions -XX:G1NewSizePercent=15 -XX:ParallelGCThreads=8 -XX:+ParallelRefProcEnabled -XX:G1HeapRegionSize=8M JAVA_OPTS_HEAP: -Xms16g -Xmx16g
我们最近遇到了一个问题,即两个 java 进程在具有 48 GB RAM 的机器上以上述配置运行,并且这两个进程继续消耗大约 20 - 22 GB 的 RAM(很少有小型进程消耗剩余内存),从而填满整个 RAM,然后触发磁盘交换,最终导致 OOM 和进程被杀死。
这似乎令人担忧,因为 NMT 既没有以有意义的方式报告此内存使用情况,也没有从 GC 日志中获得有关此使用情况的任何线索。在 NMT 统计中,应用程序内存低于 16G,元空间使用率低于 1G。
我们曾尝试将 maxMetaSpaceSize 设置为 2G,但这也无济于事。当进程运行数天时,RAM 使用量似乎无限增长。
从其他问题看来,G1 垃圾收集器确实倾向于消耗更多内存,但磁盘交换是一个令人担忧的问题。有人可以提供一些有关如何解决此问题的指示吗?
【问题讨论】:
-
关于此问题的任何更新
-
不,我们还没有找到根本原因。
-
我们也遇到过类似的情况。系统运行好几天。 15% 堆消耗,30% 总 RAM 消耗。然后,在几分钟的时间里,JVM 继续消耗所有可用的 RAM(总共 10G),然后开始交换。堆保持不变,但监控变得不稳定,因为系统没有响应,因为它只是像疯子一样分页。这是生产流量,然后有一天,只是 ZZzzang!去月球吧,爱丽丝!我们正在切换回来,看看几天后会发生什么。
标签: java memory garbage-collection g1gc