mirror of
https://github.com/VictoriaMetrics/VictoriaMetrics.git
synced 2026-05-17 08:36:55 +03:00
3f1b7a3a7f
Previously, the `lrucache` ttl was hardcoded to 3 minutes and the code comment said it was enough for most queries that are sent to vmstorage repeatedly. But it appears that it is not always the case. `indexDB` has this `tagFilters loop cache` that is used in index search optimizations (see `getMetricIDsForDateAndFilters()`). Until recently, this cache was implemented with `workingsetcache`. In [10154](https://github.com/VictoriaMetrics/VictoriaMetrics/pull/10154), this implementation was changed to `lrucache`. After this change, some users reported huge CPU utilization increase in vmstorage (see [10297](https://github.com/VictoriaMetrics/VictoriaMetrics/pull/10297)). `workingsetcache` evicts an entry after two rotations that happen every 30 minutes. I.e. the entry ttl is 1h since the last time it was retrieved from the cache. Hence the assumption that `lrucache` causes the CPU to raise because of its too aggressive eviction policy. Reverting back to `workingsetcache` helped but `lrucache` is still preferred because it occupies less memory. Since `lrucache` is preferred, its ttl needs to be increased. Instead changing the hardcoded value, the ttl was made configurable. The `tagFilters loops cache` was configured to have ttl of 1h to match the default behavior of `workingsetcache`. Although no one complained about this yet, the ttl was also increased for `tfssCache` because previously it was also implemented with `workingsetcache`. Finally, the `regexpCache` and `prefixesCache` were also configured to have 1h ttl because these caches are also during the data retrieval. Signed-off-by: Artem Fetishev <rtm@victoriametrics.com>