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