Elasticsearch慢查询故障诊断

最近在做ES搜索调优，看了一些lucene搜索的文档和代码，本文用于总结调优过程中学到的知识和自己的思考。

在抓到ES慢查询之后，会通过profile或者kibana的Search Profiler console查看具体慢在了哪里。一般在执行profile search之前，需要稍微改变query语句里的查询内容，防止cache影响测试效果。

profile主要包括shard级别的query耗时、query语句rewrite耗时以及最终lucene collector的耗时。

一般主要关注query的耗时，profile返回的query部分详细的展示了被rewrite后的查询语句以及每个子查询的耗时。包括子查询的类型(type)，子查询语句(description)，子查询耗时(time_in_nanos)和一个breakdown集合包含了lucene segements search各阶段的耗时。从这个breakdown集合中能比较清晰的看到耗时的原因，当然，前提是要理解breakdown里每个指标代表什么意思和内部的实现逻辑。

breakdown里的主要指标及lucene中的实现：

build_scorer:构造一个scorer的耗时。scorer主要用于对matching的doc进行打分和排序。build_scorer内部构造了迭代器，这个迭代器可以遍历所有matched document，构造迭代器是非常耗时的操作，因为涉及到对各子查询的docId结果集构造倒排链或bitset，并且做conjunction生成最终可被迭代的docId bitset或倒排链。大多数查询主要耗时在这一步。

next_doc: 寻找下一个匹配的document Id。这里keyword, text等文本类型的字段会利用skipList，数值类型的数据会利用Tree结构快速找的下一个匹配的docoument Id。同时，这里会记录该doc命中的子查询数量，用于最终的min_should_match之类的过滤。

advance: 类似于一个low level的next_doc。并不是所有的query都能实现next_doc，比如must查询走的advance去找下一个匹配的文档。

score: 记录socrer中对文档打分的耗时，通过Freq，normal等数据结合tf-idf等算法计算出得分。

match: 记录第二阶段打分的耗时。有些查询需要两阶段打分，比如短语查询(phrase query) "chinese love china", 第一阶段先找所有包含“chinese”、“love”、“china”三个term的文档。第二阶段再在第一阶段匹配到到的所有文档中计算“chinese”,"love","china"三个单词的位置和顺序是否满足条件，这一操作非常耗时，所以通过第一阶段缩小匹配文档的范围。

create_weight: 创建weight过程的耗时，weight就相当于lucene查询的context，里面包含了query，collector，indexreader等。

*_count: 记录方法调用次数，比如next_doc_count:2，代表next_doc方法被调用了两次。

除了query过程的详细统计，还包括：

rewrite_time: query语句被重写的耗时，lucene自己维护了一套查询语句重写逻辑，比如terms查询中如果要查询的terms个数小于16，会被重写成多个TermQuery做or结合；如果大于16会被重写成TermInSetQuery。

collector: query数据收集阶段的各种指标。包括query用到的collector的个数，类型和耗时。ES默认使用的是SimpleTopScoreDocCollector。lucene的collector主要通过reduce方法对每个segment上匹配的结果进行合并和排序，返回topN。

故障诊断过程中，除了通过profile API定位慢查询，也需要关注ES集群的整体资源使用情况，比如data node的CPU, Mem, 磁盘IO是否有瓶颈，单节点shard个数是否过多等。一般可以通过cerebro或者elasticsearch_exporter+Prometheus来监控集群状态, 也可以通过ES API查看相关指标。