Michail Anastasopoulos (2) [Avatar] Offline

the query cache statistics of my cluster contain following values:
"query_cache": {
"memory_size_in_bytes": 113744184,
"total_count": 394174905,
"hit_count": 17192100,
"miss_count": 376982805,
"cache_size": 6859,
"cache_count": 59078,
"evictions": 52219

I was wondering what these values really mean.
In other words, is this cache overused or rather underused.
And if it is underused what options do we have? Increasing indices.queries.cache.size?

radu.gheorghe (54) [Avatar] Offline
Hi Michail,

It sounds like the query cache isn't used a lot (looking at hit vs. miss, but also since it's only 113MB, and considering evictions vs current size as well). Whether that is relevant or not depends on the usecase, for example:
- if aggregations are the heaviest part of your query and not the queries ran in filter/must_not contexts (you can use the Profile API to check that, or just remove aggs from a query and see how latency changes), then even if you could improve things, it might not be noticeable
- if the query always changes (e.g. a sliding time window) then it won't be cached - in 2.x and later they only get cached if you repeat it, and only on larger segments (unless you set index.queries.cache.everything to true)

The maximum cache size defaults to 10% of heap, so unless you have a small heap (<1.5GB), you're not reaching that maximum so increasing it won't help. Evictions are likely to happen because of segment merges, and not because you're hitting the maximum size.

I hope this helps.