目录
背景介绍
JVM知识回顾
ES配置说明回顾
现状分析
调优实战
总结与展望
一. 背景介绍
项目中的服务集成了springboot-admin做服务监控，最近一直收到邮件告警，提示es出错。错误信息如下：
org.elasticsearch.ElasticsearchTimeoutException: java.util.concurrent.TimeoutException: Timeout waiting for task.
频繁收到这个告警，所以决定花时间研究一下。从报错信息看，并发超时异常。ES作为java开发的中间件，我们没有对任何代码做过修改，所以就从JVM开始着手尝试解决，同时还涉及到部分ES知识和springboot的知识。
二. JVM知识回顾
可参考另一篇学习笔记: 深入理解java虚拟机
1. JVM内存模型
- JVM gc的对象：堆
2. 堆内存
2.1 堆内存划分
- 堆区分为新生代和老年代
- 新生代又分为Eden区，from survivor区，to survivor区
- Eden区和两块较小的survivor空间。大小比例为8:1:1
- java8已经没有持久代了，改为元数据区，主要存放元数据，例如Class、Method的元信息，与垃圾回收要回收的Java对象关系不大
2.2 堆内存查看
使用 jstat -gc（-gccapacity, -gcutil）命令查看堆分配情况
- S0C：survivor0区总内存大小（Capacity）
- S1C: survivor1区总内存大小
- S0U: survivor0区当前内存大小（Used）
- S1U: survivor1区当前内存大小
- EC：Eden区总内存大小
- EU：Eden区当前内存大小
- OC：老年代总内存大小
- OU：老年代当前内存大小
- MC：meta data区总内存大小
- MU：meta data区当前内存大小
2.3 内存分配和回收策略
2.3.1 分配策略
- 大部分对象创建时，在eden区分配
- 大的对象直接进入老年代，比如很长的字符串或数组。这些对象对垃圾回收不友好。
- 长期存活的对象，将从新生代晋升到老年代
2.3.2 回收策略
- eden区满：触发一次minor gc，存活的对象复制到其中一个survivor。对象的年龄+1
- 一个survivor区满：满足晋升条件的，进入老年代。不满足的，复制到另一个survivor区
2.3.3 晋升条件的判断
- Serial和ParNew GC中通过MaxTenuringThreshold参数设定，默认为15
- Parallel收集器自动调整年龄：survivor空间中相同年龄所有对象大小大于空间的一半，大于等于该年龄的对象就直接进入老年代
2.3 关于堆划分的思考
2.3.1 大堆和小堆堆程序的影响
- 堆太大：垃圾回收时STW的时间过长，影响程序响应时间。据说ZGC（java11发布）回收器能解决这个问题。java11中ZGC的介绍
- 堆太小：垃圾回收太频繁
2.3.2 为什么要划分为不同的年代
- 每个对象的生命周期是不一样的，将不同存活时间的对象划分到不同的区，然后采用不同的垃圾回收算法
- java很多对象都是朝生夕死的，这些对象不会进入老年代。
2.3.3 为什么要有survivor区
- 没有survivor区，只有eden区的话，每进行一次minor gc，对象就被送入老年代。很容易触发full gc，影响性能
- survivor存在的目的就是减少送入老年代的对象数量，减少full gc的发生
2.3.4 为什么要设置两个survivor区
每次minor gc，通过将eden和一个survivor的内容复制到另一个survivor， 避免碎片化问题
3. 垃圾回收算法
3.1 标记-清除算法
- 最基础的收集算法
- 分为标记和清除两个阶段
- 不足之处：
- 效率问题
- 产生大量不连续的内存碎片
3.2 复制算法
- 将内存分为大小相等的两块，每次使用其中的一块
- 一块用完时，将存活的对象复制到另一块
- 现代虚拟机新生代都用该算法
- 不足：
- 内存利用率不高
3.3 标记-整理算法
- 对象存活率高时大量的复制会影响效率，老年代使用该算法
- 标记过程与标记-清除算法一样
- 后续步骤并不是清理对象，而是让所有存活的对象都向一段移动，清理边界以外的内存
3.4 分代收集算法
- 根据对象存活周期不同，采用不同的收集算法
- 新生代大量对象死亡，少量存活，采用复制算法
- 老年代对象存活率高，采用标记-清理或者标记-收集算法
4. 垃圾回收器
4.1 年代划分
- 新生代收集器有：Serial，ParNew，Paraller Scavenge
- 老年代收集器有：CMS Serial old，Parallel Old
- G1收集器可作用与新生代和老年代
- 没有连线的两个收集器不能共存，比如CMS和Paraller Scavenge
4.2 工作机制划分
- 串行收集器：Serial，Serial Old，单线程的一个回收器，简单、易实现、效率高
- 并行收集器：ParNew，Serial的多线程版，可以充分的利用CPU资源，减少回收的时间
- 吞吐量优先收集器：Parallel Scavenge
- 并发收集器：CMS（Concurrent Mark Sweep），停顿时间少优先，基于“标记-清除”算法实现。
4.3 其他说明
- java11 新出了一款ZGC收集器，性能比G1更高效（还在实验阶段）
- java5默认采用CMS收集器，java9默认收集器被G1代替
- 用户可自己指定使用哪种垃圾收集器
- 各个垃圾收集器详细介绍参考深入理解java虚拟机
4.4 CMS工作原理
- 不会等到老年代空间快满了才回收（和用户线程并发，留内存给用户线程）。配置参数为-XX：CMSInitiazingOccupanyFraction。默认为75%
- 使用标记-清除算法。整个过程分为四步：
- 初始标记：STW，标记GC Roots能关联到的对象，速度很快
- 并发标记：GC Roots Tracing过程。耗时。和用户线程一起执行（并行）
- 重新标记：STW，标记并发标记过程中程序运行导致标记变化的对象，时间比初始标记长，远比并发标记短
- 并发清除：耗时。和用户线程一起执行（并行）
三. ES配置说明回顾
可参考另外一篇笔记：Elasticsearch学习笔记
主要介绍es官网手册特别说明的一些注意点
1. 关于配置的说明
1.1 ES使用的垃圾回收器
- 默认为CMS，2.x版本官方推荐不要修改为G1，某些版本JAVA G1存在的Bug，会造成Lucene的段文件损坏。
- 不过5.x以及之后版本，没有明确说推荐或不推荐G1，默认还是用的CMS
1.2 ES内存分配要求
- 不超过32G。因为每个对象的指针都变长了，就会使用更多的 CPU 内存带宽，也就是说你实际上失去了更多的内存。
- 不要超过内存的一半，因为Lucene也需要内存，且这些内存不被JVM管理
- 如果不需要对分词做聚合运算，可降低堆内存。堆内存越小，Elasticsearch（更快的 GC）和 Lucene（更多的内存用于缓存）的性能越好。
2. 关于滚动重启的说明
- 保证不停集群功能的情况下逐一对每个节点进行升级或维护
- 先停止索引新的数据
- 禁止分片分配。cluster.routing.allocation.enable" : "none"
curl -XPUT http://{ip}:9200/_cluster/settings -d' { "transient" : { "cluster.routing.allocation.enable" : "none" } }' - 关闭单个节点，并执行升级维护
- 启动节点，并等待加入集群
- 重启分片分配。cluster.routing.allocation.enable" : "all"
curl -XPUT http://{ip}:9200/_cluster/settings -d' { "transient" : { "cluster.routing.allocation.enable" : "all" } }' - 对其他节点重复以上步骤
- 恢复索引更新数据
四. 现状分析
1. 版本及硬件情况介绍
- java：1.8.0_131
- elasticsearch：5.5.1
- es集群：4个数据节点
- os: centos7 24核 128G
- 垃圾回收器：老年代（CMS）+ 新生代（ParNew）
2. 目前堆分配情况
要针对jvm调优，必不可少的是先查看堆内存状况，有以下几种查看方法
2.1 jstat -gc命令查看堆分配情况
2.2 统计ES各个节点堆分配信息
| 节点 | 堆总大小 | 新生代 | survivor | eden | 老年代 | 元数据区 |
|---|---|---|---|---|---|---|
| 节点A | 32G | 1.46G | 0.146G | 1.16G | 30.5G | 81M |
| 节点B | 32G | 1.46G | 0.146G | 1.16G | 30.5G | 85M |
| 节点C | 32G | 1.46G | 0.146G | 1.16G | 30.5G | 81M |
| 节点D | 20G | 1.46G | 0.146G | 1.16G | 18.5G | 76M |
3. 监控工具对比
| 工具名称 | 各分区情况 | 数据是否直观 | 是否可查看历史数据 | 是否免费 | 备注 |
|---|---|---|---|---|---|
| jstat | 是 | 否 | 否 | 是 | 主要用于查看各分区大小 |
| ElasticHQ | 否 | 是 | 否 | 是 | 主要用于浏览es整体信息 |
| cerebro | 否 | 是 | 否 | 是 | 主要用于浏览es整体信息 |
| x-pack | 否 | 是 | 是 | 试用期一年 | 试用期到相关功能不可用，不影响现有功能。6.3版本x-pack已经开源，后续版本可能会免费 |
- 由于线上报异常邮件的时间是不确定的，不可能随时盯着监控面板看，所有必须有查看历史数据的功能，因此x-pack是我们监控的首选工具
- x-pack监控功能只是其中之一，但是真的非常强大，强烈推荐！！同时期待ES官方尽快使之免费
- 网上有破解x-pack的方法，将jar包反编译之后修改代码，再打包回去，还没做尝试。
x-pack安装过程的一些小问题总结
第一步：证书申请
- register.elastic.co/marvel_regi…
- 填写信息后，得到一个json文件，导入到es中, 有效期一年。
curl -XPUT 'http://{ip}:9200/_xpack/license?acknowledge=true' -H "Content-Type: application/json" -d @sivabalan-nagarajan-2327c0fa-f56b-443a-a3d6-abef7ecf2220-v5.json
第二步：安装x-pack插件, 包括es和kibana
./bin/kibana-plugin install x-pack 安装很慢，先把文件下载下来，用下一个命令安装
./bin/elasticsearch-plugin install file:///home/breakpad/softs/x-pack-5.5.1.zip
第三步：修改配置文件
es配置文件里，只启用监控功能
xpack.security.enabled: false
xpack.monitoring.enabled: true
xpack.graph.enabled: false
xpack.watcher.enabled: false
kibana配置文件里，只启用监控功能
xpack.security.enabled: false
xpack.monitoring.enabled: true
xpack.graph.enabled: false
xpack.reporting.enabled: false
报错问题解决
rpm安装后，systemctl方式启动kibana报权限不足的问题？
- 卸载x-pack，以kibana用户去安装 sudo -u kibana bin/kibana-plugin install file:///usr/share/kibana/x-pack-5.5.1.zip
- 还是报权限错误，修改报错的文件权限都为kibana
- 安装包权限报错，修改安装包权限为kibana
kibana启动后网页打不开怎么解决？
- 在config/kibana.yml里配置日志路径：logging.dest: /var/log/kibana.log
- 修改日志权限 touch /var/log/kibana.log chown kibana:kibana /var/log/kibana.log
- 日志也没有错，但是浏览器就是打不开。最后无意间换了个浏览器竟然正常了，再重新把之前打不开的chrome浏览器升级之后，也能正常打开了！！
4. x-pack监控情况分析（以节点B，周期为7天为例）
曲线中每一天大概24个点，即计算的是每个小时的数据
4.1 gc次数：平均值为250次/h 左右
4.2 minor gc耗时：平均值为10000ms/h
4.3 full gc后：剩余堆大小：4.2G，两次full gc的时间分别为2.224s，2.438s
5. 观察到的现象
- 新生代和老年代分配比例不合理，新生代太小，老年代太大
- 网上很多文章指出新生代和老年代的默认比例为1:2，但是通过观察发现并不是这样(我们的机器上约是1:20)。
- 具体原因在网上目前只找到这样一篇文章有过说明。CMS默认新生代是多大？
- 大致就是：取默认NewRatio计算出来的值和另外一个公式计算出来的值对比，取小的那一个
- 计算公式为：计算机核数*某个参数（64M）*13/10。我们的机器算出来的值为2G，勉强符合这个说法。
- 新生代垃圾回收频繁
- 老年代收集后：有效内存只达4G左右（活跃数据）
6. 针对观察到现象的初步分析和解决
- 新生代太小：导致minior gc回收频繁，可适当加大新生代大小
- 老年代太大：导致major gc或full gc回收时间过长，可适当减少老年代大小
- 如何确定新生代老年代大小：根据美团gc优化实战文章所述：
- 总大小：3-4倍活跃数据大小：
- 节点B为4.2G*4，我们设置为20G。
- 其他机器大概为3.6G*4，我们设置为16G
- 新生代：1-1.5倍活跃数据大小
- 老年代：总大小-新生代。综上，我们设置新生代：老年代=1:4
- 总大小：3-4倍活跃数据大小：
五. 调优实战
通过以上分析发现的问题，然后尝试调整参数，并且观察调整后的监控结果，验证我们的推测是否正确。
1. 修改配置参数
- 文件为{es_home}/config/jvm.options
2. 修改后的堆配置参数
| 节点 | 堆总大小 | 新生代 | survivor | eden | 老年代 | 元数据区 |
|---|---|---|---|---|---|---|
| 节点A | 16G | 3.2G | 320M | 2.56G | 12.8G | 77M |
| 节点B | 20G | 4G | 400M | 3.2G | 16G | 66M |
| 节点C | 16G | 3.2G | 320M | 2.56G | 12.8G | 77M |
| 节点D | 16G | 3.2G | 320M | 2.56G | 12.8G | 77M |
3. 修改后的监控信息
3.1 gc次数整体呈下降趋势
3.2 gc耗时整体呈下降趋势，full gc时间大致在900ms左右
4. springboot参数的调整
- 通过对JVM参数调整后，发现还是有不定时报警的情况。于是研究了一下springboot-admin的原理，它是基于springboot-actuator做了封装，然后看了一下springboot-actuator的原理，找到了其中一个很重要的参数：
management.health.elasticsearch.response-timeout - 该参数表示监控程序向es集群发送心跳，允许最大的响应时间的多少？ 聪明的你应该明白了，如果发送心跳的时候，es的JVM正在执行垃圾回收，STW导致响应迟迟得不到回复，就会收到邮件告警。它的默认值是100ms，所以必须将该值设置为至少超过minior gc的时间。
- 但是，如果发送心跳的时候，恰好JVM正在执行full gc，因为STW的时间一般比较长，所以你必然会收到告警邮件，除非你把response-timeout的值设置为比full gc的时间还长
- 综上分析，需要根据垃圾回收的时间，给该值设置合理的值。
六. 总结与展望
1. 最终优化总结
1.1 关于JVM的调优
- 减少ES节点分配给JVM的堆大小
- 调整新生代和老年代的比例
1.2 关于springboot的调优
- 加大springboot-actuator针对Elasticsearch健康检查时的响应时间（默认为100ms）
2. 展望
- 业务优化：此次优化仅仅从JVM的角度做了参数调整，es官方文档其实给出很多高效使用es的方法。后续优化可以从业务的角度去分析，包括：
- 很多不需要分词的字段，都没有做配置，默认都分词了。特别影响性能。
- 很多查询没有用filter，用了query。无法缓存。
- 同时，期待将来ZGC投入使用，同时ES很好的兼容ZGC，或许那时就不需要任何调优了（不管多大的堆，gc时间在10ms内）。
七. 参考
- 《深入理解java虚拟机》
- 《elasticsearch权威指南》
- 美团gc优化实战
