首页 > 其他分享> 文章详细

elasticsearch 大集群最基本，也是最重要的两个配置gc和指针压缩

2021-02-28 16:33:43 阅读：309 来源： 互联网

标签：XX gc Compressed heap elasticsearch 指针 true Oops

本来不想写这篇的，因为实在太过基础，但就是在线上生产环境的es集群上出现了这种类问题，这两个配置也适于于所有的jvm栈服务

公司规模也不算小，很久前因为es日常维护和搭建和升级都交给平台组了，平台组保证es的日常稳定，但并不会主动作业务层相关的优化，高负载影响业务排查时，实在不敢相信，会碰到这两个问题。

1 gc

简直离谱，不想吐槽，都2020年了es还在用cms，改为g1，性能提升近50%，测试环境也就算了，生产环境在cms上跑了近一年，敢信？

2 指针压缩

指针压缩未生效的情况下，集群跑了近2年

不过这个虽然离谱，倒也能理解，网上找个的'最佳实践'，未结合执行环境，就可能会出现这个问题

https://www.elastic.co/guide/en/elasticsearch/reference/7.2/heap-size.html

查看线上es，jvm heap配置的是 -Xms32700m -Xmx32700m

ps -ef |grep elasticsearch
elastic+ 20033     1 99 Apr10 ?        615-02:04:15 /bin/java -XX:+UseG1GC -XX:InitiatingHeapOccupancyPercent=35 -XX:G1ReservePercent=20 -XX:MaxGCPauseMillis=400 -XX:+DisableExplicitGC -XX:+AlwaysPreTouch -server -Xss1m -Djava.awt.headless=true -Dfile.encoding=UTF-8 -Djna.nosys=true -Djdk.io.permissionsUseCanonicalPath=true -Dio.netty.noUnsafe=true -Dio.netty.noKeySetOptimization=true -Dio.netty.recycler.maxCapacityPerThread=0 -Dlog4j.shutdownHookEnabled=false -Dlog4j2.disable.jmx=true -Dlog4j.skipJansi=true -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintClassHistogram -XX:+PrintTenuringDistribution -XX:+PrintGCApplicationStoppedTime -XX:GCLogFileSize=10M -XX:NumberOfGCLogFiles=10 -Xloggc:/var/log/elasticsearch/datanode/gc.log -Xms32700m -Xmx32700m -Des.path.home=/ssd/elastic_app/elasticsearch-datanode-5.3.0 -cp /ssd/elastic_app/elasticsearch-datanode-5.3.0/lib/elasticsearch-5.3.0.jar:/ssd/elastic_app/elasticsearch-datanode-5.3.0/lib/* org.elasticsearch.bootstrap.Elasticsearch -d

按es官方的介绍执行

java  -XX:+UnlockDiagnosticVMOptions -XX:+PrintCompressedOopsMode -Xms32700m -Xmx32700m -version

Protected page at the reserved heap base: 0x00007f953d200000 / 2097152 bytes
heap address: 0x00007f953d400000, size: 32700 MB, Compressed Oops mode: Non-zero based:0x00007f953d3ff000, Oop shift amount: 3
Narrow klass base: 0x00007f9444220000, Narrow klass shift: 0
Compressed class space size: 1073741824 Address: 0x00007f9444220000 Req Addr: 0x00007f9d39000000
openjdk version "1.8.0_144"
OpenJDK Runtime Environment (build 1.8.0_144-b01)

主要看这行 Compressed Oops mode: Non-zero
heap address: 0x00007f953d400000, size: 32700 MB, Compressed Oops mode: Non-zero based:0x00007f953d3ff000, Oop shift amount: 3

显然没有应用指针压缩
多次测试，发现os指针压缩的临界点是30700m Compressed Oops mode: Zero based

java  -XX:+UnlockDiagnosticVMOptions -XX:+PrintCompressedOopsMode -Xms30700m -Xmx30700m -version
heap address: 0x0000000081400000, size: 30700 MB, Compressed Oops mode: Zero based, Oop shift amount: 3

30800m Compressed Oops mode: Non-zero

java  -XX:+UnlockDiagnosticVMOptions -XX:+PrintCompressedOopsMode -Xms30800m -Xmx30800m -version

heap address: 0x00007f2e10000000, size: 30800 MB, Compressed Oops mode: Non-zero based:0x00007f2e0ffff000, Oop shift amount: 3

记得以前看过的一个压测报告，使用0址压缩的32G mem = 未使用指针压缩的45G mem

指针压缩未生效，保守估计，内存浪费了(45-32)/32=40%，cpu不好定量，在20%到50%之间

整体性能损失30%左右

这个0址压缩的阈值在不同os下是不同的，相同os不同版本可能也会有少许的区别，不作验证，直接抄着用，就可能出现指针压缩未生效的问题

标签：XX,gc,Compressed,heap,elasticsearch,指针,true,Oops
来源： https://www.cnblogs.com/zihunqingxin/p/14459556.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

ICode9

elasticsearch 大集群最基本，也是最重要的两个配置gc和指针压缩