java 折线毛刺_聊聊 Elasticsearch 的查询毛刺

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

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

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

GC 的影响

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

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

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

curl -sXGET "http://localhost:9200/_cat/nodes?h=name,port,segments.memory,segments.index_writer_memory,segments.version_map_memory,segments.fixed_bitset_memory,fielddata.memory_size,query_cache.memory_size,request_cache.memory_size&v"

HBase 通过 offheap 的方式降低 JVM 占用，来避免 FGC，es 将 FST offheap 后也大幅降低了 JVM 占用情况，不过 FST offheap 之后有可能会被系统清理，再次查询 FST 就会发生 io，也会造成查询延迟不稳定，不过这种概率非常小。而在 es 中聚合，scroll等操作都可能导致 JVM 被大幅占用，增加了不确定性。

系统 cache 失效

查询，以及聚合，需要访问磁盘上不同的文件，es 建议为系统 cache 保留一半的物理内存空间，当系统 cache 失效，发生磁盘 io，对查询延迟产生明显的影响。pagecache 什么时候会失效？使用 pagecache 的地方很多，linux 默认会缓存绝大部分的文件读写，例如查询，写日志，入库写 segment 文件，merge 时读写的文件，以及es 所在节点部署的其他的程序、脚本文件执行的对 io 上面的操作等都会抢占 pagecache。linux 按一定策略和阈值来清理 pagecache，应用层无法控制哪些文件不被清理。

因此我们需要了解一个查询语句在 io 上的需求，主要是以下两个问题：

查询过程需要实时读取哪些文件？

一次查询需要几次 io？读取多少字节？消耗多少时间？

查询过程需要实时读取哪些文件

es 中的查询是一个复杂的过程，不同的查询类型需要访问不同的 lucene 文件，我将常见类型的查询可能访问的文件整理如下：