Elasticsearch没有设置任何置新生代和老年代,按理说应该按照默认的8:2:1的比例,但是很快,查看内存发现新生代是 900M arthas查看的
使用的是CMS垃圾回收器,经过百度发现
Eden 区的大小通常由 JVM 的堆内存分配策略和应用程序的内存需求来决定。Elasticsearch 在其默认配置中会根据 JVM 的堆内存大小自动计算堆内存的各个区域的大小,包括 Eden 区、Survivor 区和老年代。默认情况下,Elasticsearch 使用 G1 垃圾回收器,它会根据堆内存大小自动调整这些区域的大小。
但是我尝试修改 -Xms 和 -Xmx两个参数,无论是设置20G还是16G,尝试降低和增加,这个900M都是不动的,就非常的诡异。
后来显示的设置
-XX:NewSize=6G
-XX:MaxNewSize=6G
这个才发生变化,有人知道这个是为什么吗?/usr/jdk64/jdk1.8.0_112/bin/java -Xms31g -Xmx31g -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -Des.networkaddress.cache.ttl=60 -Des.networkaddress.cache.negative.ttl=10 -XX:+AlwaysPreTouch -Xss1m -Djava.awt.headless=true -Dfile.encoding=UTF-8 -Djna.nosys=true -XX:-OmitStackTraceInFastThrow -Dio.netty.noUnsafe=true -Dio.netty.noKeySetOptimization=true -Dio.netty.recycler.maxCapacityPerThread=0 -Dlog4j.shutdownHookEnabled=false -Dlog4j2.disable.jmx=true -Djava.io.tmpdir=/tmp/elasticsearch-1060148110909776643 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=data -XX:ErrorFile=logs/hs_err_pid%p.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintTenuringDistribution -XX:+PrintGCApplicationStoppedTime -Xloggc:logs/gc.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=32 -XX:GCLogFileSize=64m -Des.path.home=/usr/hdp/current/elasticsearch_client -Des.path.conf=/usr/hdp/current/elasticsearch_client/config -Des.distribution.flavor=default -Des.distribution.type=tar -cp /usr/hdp/current/elasticsearch_client/lib/* org.elasticsearch.bootstrap.Elasticsearch -p /usr/hdp/current/elasticsearch_client/elasticsearch.pid
Elasticsearch没有设置任何置新生代和老年代的原因可能是以下几点:
因此,看到的新生代是900M可能是因为堆内存大小是31G,按照默认的比例2:1分配给新生代和老年代,那么新生代就是10.33G,然后按照默认的比例8:1分配给Eden区和Survivor区,那么Eden区就是9.29G,Survivor区就是0.52G。由于Survivor区有两个,所以新生代中可用的空间就是9.29G+0.52G=9.81G,约等于900M。
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。