背景
项目上是用 ES 做数据库，存储的告警数据，量级在千万级别左右。测试在压测之后，系统频繁出现告警记录查询报错，系统不可用。基于此排查分析项目上 Elasticsearch 的使用是否合理。
版本及硬件
- 环境：10.xx.xxx.xx
- jdk：1.8.0
- elasticsearch：6.5.4
- es集群：1个client(预处理节点)，1个data(即做主节点，又做数据节点)
- os：centos7 64核 128G
- 垃圾回收器：-XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -XX:+AlwaysPreTouch
ES JVM 分析
要针对 jvm 调优，必不可少的是先查看堆内存状况，使用如下命令查看
jstat -gc
jstat -gc命令查看堆分配情况
- 进入elasticsearch容器内部：kubectl exec -it -n logging elasticsearch-data-0 /bin/sh
- 查看堆内存使用情况：/opt/jdk-xx/bin/jstat -gc 1 1000
- 各参数详解参考：https://www.dcr-stephen.cn/post/5
ES各节点分配信息
| 节点 | 堆总大小 | 新生代 | survivor | eden | 老年代 | 元数据区 |
| data | 15G | 0.243G | 0.024G | 0.195G | 14.756G | 77M |
观察到的现象
- 新生代和老年代分配比不合理，新生代太小，老年代太大
- 新生代垃圾回收频繁
网上很多文章指出新生代和老年代的默认比例为1:2，但是通过观察发现并不是这样(我们的机器上大约是1:60)。
这篇文章解释了原因：https://bugs.openjdk.java.net/browse/JDK-8153578
查看k8s日志发现elasticsearch频繁发生minior GC，而且每次GC需要花费200-500ms，截图如下：kubectl logs -f -n logging elasticsearch-data-0 --tail=100
初步分析和解决
- 新生代太小：导致minior gc回收频繁，可适当加大新生代大小
- 老年代太大：导致major gc或full gc回收时间过长，可适当减少老年代大小
- 如何确定新生代老年代大小：根据 美团gc优化实战 文章所述：
- 总大小：3-4倍活跃数据大小
- 新生代：1-1.5倍活跃数据大小
- 老年代：总大小-新生代
调优实战
需总共给 Elasticsearch 分配 22 GB内存。原因如下：
elasticsearch-data
- 根据 gc 日志可算出活跃数据大小约为 3g，那么各分区大小可设为：
- 总堆：12g=3g*4，新生代：4.5g=3g*1.5，老年代：7.5g=12g-4.5g
- 因推送并发高时需要频繁的写入 es，会产生大量的短期对象，这种场景应该加大新生代来降低频繁的 minor GC，从而提高并发性
-
综上：elasticsearch-data 的调优参数为：-Xms15g -Xmx15g -Xmn10g
elasticsearch-client
- 根据 gc 日志可算出活跃数据大小约为 450M，那么各分区大小可设为：
- 总堆：8g=2g*4，新生代：3g=2g*1.5，老年代：5g=8g-3g
- 因 elasticsearch-client 只作为 ingest 节点，主要是对数据进行前置处理、过滤、转换等，内存可以相对调小一些
-
综上：elasticsearch-client 的调优参数为：-Xms4g -Xmx4g -Xmn2g
参考
- 《深入理解java虚拟机》
- https://tech.meituan.com/2017/12/29/jvm-optimize.html
- https://tech.meituan.com/2017/12/29/jvm-optimize.html
