深入探究Elasticsearch查询毛刺

如果业务对查询延迟很敏感，Elasticsearch 查询延迟中的毛刺现象就是比较困扰的一类问题，由于出现毛刺的时间点已经过去，无法稳定复现，对于根因的分析比较困难，无法用系统化调试的思想，从现象出发逐步推理，定位问题，能做的通常就是看一下监控系统对应时间点的指标情况，而在 es 中，导致查询延迟发生波动的因素非常多，今天我们来列举一下可能的因素，并尝试用对应的方法来定位和解决他们

通常一个系统中会有多种不同的查询同时存在，他们本身正常的查询延迟就可能存较大差异，因此即使系统在理想状态下，查询延迟的曲线也可能存在较大波动，特别是查询条件不固定，某些查询本身就耗时较长。我们只讨论一个特定的查询语句在某个时刻产生了较大延迟，即这个查询语句正常不应该耗时那么久。

另外 es 和 lucene 层面的查询缓存只是一种优化，查询缓存本身并不能保证查询延迟，因此不在本文讨论范畴。

GC 的影响

查询延迟受 GC 的影响是常见因素之一，一个查询被转发的相关分片，任意节点产生一个长时间的 GC 都会导致整个查询耗时变长。

定位方式：
查看对应时间点的节点 GC 指标，参考 kibana 或 gc log

解决方式：
堆内存不足可能的因素比较多，例如配置的 JVM内存较小，open 的索引过多，导致 FST 占用空间过大（未开启 offheap 的情况下），聚合占用了大量内存，netty 层占用大量内存，以及 cache 占用的内存等，主要是根据自己的业务特点，找到内存被谁占用了，然后合理规划JVM 内存空间。可以通过 REST API 或 MAT 分析内存，参考命令：

curl -sXGET