Elasticsearch的Query Cache 知识梳理

双十一来临，大家应该要对所有索引都做做健康检查了，由于最近压力上不去，所以盯上了Query Cache，由于之前Query Cache没有怎么注意，一直用的是默认配置，所以导致我发现cache的效率一直没上去。如下图，初步一看命中率50%+， Memory size 也没伤到预订大小，这里先不逐个字段解释，下面就以问答的形式来介绍一下这个query cache。

默认值的cache 状况

---

什么是Query Cache

简单来看可以这样理解，一个ES的查询会先被parse 成一系列的Lucene 的phrase，这些phrases 中的filter语句，如果对于查询条件是一样的时候，其实结果集是已定的，那么这些phrase 其实就是可以存放在一个地方当做cache用，这个就是 query cache。在ES里，这个是Node级别的配置，必须通过 yml配置里面去配置。

Query Cache 如何配置size 大小

如上图所示，如果默认的话，ES将会用10%的HEAP大小来存所有的Query Cache，这个配置必须通过yml文件来调整，但是从文章开头的截图可以出，我30G的HEAP最后只是使用了800MB的cache，为什么并不是配置的10%也就是3G呢？那就要看另外一个限制的配置

Query Cache配置最大个数

从截图中可以发现一个非常醒目的整数，这个就是另外一个限制条件，最大个数，这个同样是Node级别的，Query level，默认就是10000，就是说，不管size 有没有达到，数据到了10000，query cache也不会再增加了。
可以通过
indices.queries.cache.count=10000
的方式在yml配置

但是又有人会问，为什么我配置了10000，但是我还是会发现有超过10000的情况？比如：10123这样；
那就要看看下一个问题

Query Cache 的数据结构是怎么存的

简单来说ES的内部数据结构就是一个MAP，key就是一个具体的query，而value就是一个segment的 K/V, 而上面的10000的配置，只是Query 这个level，就是说真正的cache_size 是 Query size * segment nums， 如果你有2个segment，那么你看到的state数据很可能是cache_size:20000

为什么在文档没看到有这个cache.count的说明和配置？

看下图就明白了，其实如果看源代码的话你就知道怎么配了。。。

怎么判断哪些Query 会被cache

这个问题可以拆分成2个子问题：

• 这个Query 会还是不会被cache
• 这个Query请求多少次后会被cache

可以从UsageTrackingQueryCachingPolicy.java 这个类里面找答案；
其中第一个问题是

关于上面这几个Query 都不会被cache，对于第一个，TermQuery，官方的说法是从ES5开始，他们觉得从Term 的链表中去找数据已经足够快了，所以是不需要再去缓存了；其他的则是一些联合查询，或者嵌套查询，不应该把外层cache

对于第二个问题则可以看代码：

分两种，如果是Costly的query，则只需要访问2次就会被cache了。

为什么明明限制了cache.size,但是为什么dump出来发现cache的占用还是大于阈值

要回答这个问题就比较复杂了，简单一句话就是：要估算一个Query最终占用多少空间，其实是非常复杂的，如果对这个问题感兴趣，我建议必须真的一定务必要认真阅读一下下面这两个issue，你会受益匪浅的

query cache used memory calculating is not correct, which cause non-stopping old gc

Potential memory/cache problem in 5.5.2

那有办法避免cache过大OOM么？

目前来看如果你的查询真的非常复杂，真的很容易有cache 泄漏的话，那么最简单暴力的办法就是去减少cache.count,比如设置到1000（默认10000）
官方已经很贴心的帮你这么做了,如果你用的是下面以后的版本，那么你的默认cache.count是被设置成1000了

---

结尾

好了，如果你完成了这一系列的配置之后，剩下就是去观察你的GC频率，HEAP使用，还有query_cache的states了。
下面放出我的调优结果：

• Memory size已经可以接近配置的3G
• cache size 调成了30000
• 命中率提升到75% 以上

希望大家双十一性能爆表！还有cache 的问题欢迎来聊。