前言

最近要对公司的es集群进行一些优化操作，这里整理并记录一下优化的过程，以及优化前后对比。

回到顶部

环境信息

es 7.4 版本
master节点 3台
data节点 10台
jdk 版本 11

master 节点和 data 节点角色是分离。节点数量共 13 台。

回到顶部

优化操作

主要是针对 ES 集群本身的一些配置和 JVM级别的优化配置。

`一、jvm.options`

之前默认的是 cms + parNew 垃圾回收器。替换为G1 垃圾回收器。

去掉：

-XX:+UseConcMarkSweepGC
-XX:CMSInitiatingOccupancyFraction=75
-XX:+UseCMSInitiatingOccupancyOnly

新增:

-XX:+UseG1GC
# full gc效率更高
-XX:+ExplicitGCInvokesConcurrent
-XX:+UseGCOverheadLimit
# 启动并发GC周期时的堆内存占用百分比.
-XX:InitiatingHeapOccupancyPercent=40

# 指定STW工作线程的数量
-XX:ParallelGCThreads=20
# 标记线程的数量
-XX:ConcGCThreads=8
# G1为分配担保预留的空间比例 默认10%
-XX:G1ReservePercent=15
# 表示每次GC最大的停顿毫秒数，默认200，减少该值会增加系统load。
-XX:MaxGCPauseMillis=100

注：这里我之前只指定了ConGCThreads，启动ES集群报错，查询后说需要指定XX:ParallelGCThreads参数，并且这个参数，需要大于ConGCThreads参数值。使用公式：ParallelGCThreads = 8 + ((N - 8) * 5/8) = 3 +（（5*CPU）/ 8）；同时这个参数只要是并行 GC 都可以使用，不只是 ParNew。

`二、elasticsearch.yml`

新增：

# 缓存配置
# 分片级请求缓存模块在每个分片上缓存本地结果，默认1%
indices.requests.cache.size: 2%
# 节点查询缓存，默认10%
indices.queries.cache.size: 10%
# 字段数据缓存设置，默认无限制
indices.fielddata.cache.size: 10%
# 字段数据缓存设置断路器，默认50%
indices.breaker.fielddata.limit: 40%


# 恢复配置
# 初始化数据恢复时,并发恢复线程的个数,默认为4
cluster.routing.allocation.node_initial_primaries_recoveries: 6

注：这里我的es版本为7.4，小版本的差异配置也比较多，大家根据自己的版本去实际配置，不可盲目配置。JVM的参数配置可以放心食用~

回到顶部

观察

稳定运行了一段时间后，观察了下集群的性能。这里也给出对比图。

1。首先是GC 次数和 GC 时间：

可以看到前后对比相当明显。

jvm 毛刺

可以看出JVM堆大小变得较为平滑，没有之前很明显的毛刺现象，说明FULL次数减少。

索引时间
延迟

回到顶部

总结

可以看到JVM gc次数，时间，索引时间，延迟都有明显的改善，这次调优总体是成功的！并且观察3周内没有发生FULL GC，连FULL GC都被完全“干掉”了。

晴日暖风生麦气，绿阴幽草胜花时。——王安石《初夏即事》

__EOF__

本文作者：彬在俊
本文链接：https://www.cnblogs.com/erlou96/p/16878272.html
关于博主：评论和私信会在第一时间回复。或者直接私信我。
版权声明：本博客所有文章除特别声明外，均采用 BY-NC-SA 许可协议。转载请注明出处！
声援博主：如果您觉得文章对您有帮助，可以点击文章右下角【推荐】一下。您的鼓励是博主的最大动力！