记一次Elasticsearch优化总结

目录

背景介绍

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存在的目的就是减少送入老年代的对象数量࿰