G1垃圾收集器的高内存使用问题 [英] High memory usage issues with G1 Garbage collector

查看:852
本文介绍了G1垃圾收集器的高内存使用问题的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们最近一直在使用以下配置测试G1垃圾收集器:

We have been testing out G1 garbage collector recently with the following configuration:

-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

-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和进程被杀死.

We had recently come across an issue recently where two java processes were running with the above configuration on a box with 48 GB RAM and both the processes went on to consume around 20 - 22 GB of RAM each (few small processes consuming the remaining memory), thus filling the entire RAM and then it triggered disk swaps which finally led to the OOM and process getting killed.

这似乎令人担忧,因为NMT既没有以有意义的方式报告此内存使用情况,也没有从GC日志中获得有关此使用情况的任何线索.在NMT统计数据中,应用程序内存不足16G,而元空间使用率不足1G.

This seems worrying because neither the NMT reports this memory usage in a meaningful way nor do we get any clues for this usage from the GC logs. In the NMT stats, the application memory was under 16G and the metaspace usage was under 1G.

我们曾尝试将maxMetaSpaceSize设置为2G,但这也无济于事.当进程运行数天时,RAM的使用似乎无限增长.

We had tried setting maxMetaSpaceSize to 2G but that didn't help either. The RAM usage seems to grow unbounded when the process is running for days.

从其他问题来看,G1垃圾回收器的确确实倾向于消耗更多的内存,但是磁盘交换是一个令人担忧的问题.有人可以提供一些有关如何解决此问题的指示吗?

From the other questions it does seem that G1 garbage collector does tend to consume more memory but the disk swaps is a worrying issue. Could someone please provide some pointers on how this issue could be resolved?

推荐答案

至于我想发表评论,我都将其作为答案.

As to long for a comment I put it in as an answer.

很好的读物,它解释了

A good reading which explains why a java process might consume more memory than -Xmx. Based ony our provided information I believe this would be also the reason in your case.

对于G1,有一个OBE G1垃圾收集器入门有关G1GC功能的详细信息.在那里查看Recommended Use Cases for G1.也许您不会从使用G1中受益.

For G1 there is an OBE Getting Started with the G1 Garbage Collector with details about the function of the G1GC. Have a look there for Recommended Use Cases for G1. Maybe you would not benefit from using G1.

来自OBE( O 种族 B y E 示例)

cited from from the OBE (Oracle By Example)

如果您使用的是CMS或ParallelOldGC,并且您的应用程序没有经历长时间的垃圾收集暂停,那么可以继续使用当前的收集器.

If you are using CMS or ParallelOldGC and your application is not experiencing long garbage collection pauses, it is fine to stay with your current collector.

这篇关于G1垃圾收集器的高内存使用问题的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆