diff --git a/app/vmselect/promql/rollup_result_cache.go b/app/vmselect/promql/rollup_result_cache.go index 2f7229bfa..9d0213f01 100644 --- a/app/vmselect/promql/rollup_result_cache.go +++ b/app/vmselect/promql/rollup_result_cache.go @@ -29,6 +29,7 @@ var ( cacheTimestampOffset = flag.Duration("search.cacheTimestampOffset", 5*time.Minute, "The maximum duration since the current time for response data, "+ "which is always queried from the original raw data, without using the response cache. Increase this value if you see gaps in responses "+ "due to time synchronization issues between VictoriaMetrics and data sources") + resetRollupResultCacheOnStartup = flag.Bool("search.resetRollupResultCacheOnStartup", false, "Whether to reset rollup result cache on startup") ) var rollupResultCacheV = &rollupResultCache{ @@ -64,7 +65,12 @@ func InitRollupResultCache(cachePath string) { cacheSize := getRollupResultCacheSize() var c *workingsetcache.Cache if len(rollupResultCachePath) > 0 { - logger.Infof("loading rollupResult cache from %q...", rollupResultCachePath) + if *resetRollupResultCacheOnStartup { + logger.Infof("removing rollupResult cache at %q becasue -search.resetRollupResultCacheOnStartup command-line flag is set", rollupResultCachePath) + fs.MustRemoveAll(rollupResultCachePath) + } else { + logger.Infof("loading rollupResult cache from %q...", rollupResultCachePath) + } c = workingsetcache.Load(rollupResultCachePath, cacheSize) mustLoadRollupResultCacheKeyPrefix(rollupResultCachePath) } else { diff --git a/docs/CHANGELOG.md b/docs/CHANGELOG.md index 0860ea37e..249eee04e 100644 --- a/docs/CHANGELOG.md +++ b/docs/CHANGELOG.md @@ -34,6 +34,7 @@ The sandbox cluster installation is running under the constant load generated by * FEATURE: all VictoriaMetrics components: add support for empty command flag values in short array notation. For example, `-remoteWrite.sendTimeout=',20s,'` specifies three `-remoteWrite.sendTimeout` values - the first and the last ones are default values (`30s` in this case), while the second one is `20s`. * FEATURE: [vmagent](https://docs.victoriametrics.com/vmagent.html) and [single-node VictoriaMetrics](https://docs.victoriametrics.com): add support for data ingestion via [DataDog lambda extension](https://docs.datadoghq.com/serverless/libraries_integrations/extension/) aka `/api/beta/sketches` endpoint. See [these docs](https://docs.victoriametrics.com/#how-to-send-data-from-datadog-agent) and [this feature request](https://github.com/VictoriaMetrics/VictoriaMetrics/issues/3091). Thanks to @AndrewChubatiuk for [the pull request](https://github.com/VictoriaMetrics/VictoriaMetrics/pull/5584). * FEATURE: [VictoriaMetrics cluster](https://docs.victoriametrics.com/Cluster-VictoriaMetrics.html): add `-disableReroutingOnUnavailable` command-line flag, which can be used for reducing resource usage spikes at `vmstorage` nodes during rolling restart. Thanks to @Muxa1L for [the pull request](https://github.com/VictoriaMetrics/VictoriaMetrics/pull/5713). +* FEATURE: add `-search.resetRollupResultCacheOnStartup` command-line flag for resetting [query cache](https://docs.victoriametrics.com/#rollup-result-cache) on startup. See [this feature request](https://github.com/VictoriaMetrics/VictoriaMetrics/issues/834). * FEATURE: [dashboards/vmagent](https://grafana.com/grafana/dashboards/12683): add `Targets scraped/s` stat panel showing the number of targets scraped by the vmagent per-second. * FEATURE: [dashboards/all](https://grafana.com/orgs/victoriametrics): add new panel `CPU spent on GC`. It should help identifying cases when too much CPU is spent on garbage collection, and advice users on how this can be addressed. diff --git a/docs/README.md b/docs/README.md index 4f2fc1f45..916fa0606 100644 --- a/docs/README.md +++ b/docs/README.md @@ -2313,6 +2313,21 @@ Sometimes it is needed to remove such caches on the next startup. This can be do In this case VictoriaMetrics will automatically remove all the caches on the next start. See [this issue](https://github.com/VictoriaMetrics/VictoriaMetrics/issues/1447) for details. +It is also possible removing [rollup result cache](#rollup-result-cache) on startup by passing `-search.resetRollupResultCacheOnStartup` command-line flag to VictoriaMetrics. + +## Rollup result cache + +VictoriaMetrics caches query reponses by default. This allows increasing performance for repated queries +to [`/api/v1/query`](https://docs.victoriametrics.com/keyconcepts/#instant-query) and [`/api/v1/query_range`](https://docs.victoriametrics.com/keyconcepts/#range-query) +with the increasing `time`, `start` and `end` query args. + +This cache may work incorrectly when ingesting historical data into VictoriaMetrics. See [these docs](#backfilling) for details. + +The rollup cache can be disabled either globally by running VictoriaMetrics with `-search.disableCache` command-line flag +or on a per-query basis by passing `nocache=1` query arg to `/api/v1/query` and `/api/v1/query_range`. + +See also [cache removal docs](#cache-removal). + ## Cache tuning VictoriaMetrics uses various in-memory caches for faster data ingestion and query performance. @@ -2377,11 +2392,12 @@ VictoriaMetrics accepts historical data in arbitrary order of time via [any supp See [how to backfill data with recording rules in vmalert](https://docs.victoriametrics.com/vmalert.html#rules-backfilling). Make sure that configured `-retentionPeriod` covers timestamps for the backfilled data. -It is recommended disabling query cache with `-search.disableCache` command-line flag when writing +It is recommended disabling [query cache](#rollup-result-cache) with `-search.disableCache` command-line flag when writing historical data with timestamps from the past, since the cache assumes that the data is written with the current timestamps. Query cache can be enabled after the backfilling is complete. -An alternative solution is to query [/internal/resetRollupResultCache](https://docs.victoriametrics.com/url-examples.html#internalresetrollupresultcache) handler after the backfilling is complete. This will reset the query cache, which could contain incomplete data cached during the backfilling. +An alternative solution is to query [/internal/resetRollupResultCache](https://docs.victoriametrics.com/url-examples.html#internalresetrollupresultcache) +after the backfilling is complete. This will reset the [query cache](#rollup-result-cache), which could contain incomplete data cached during the backfilling. Yet another solution is to increase `-search.cacheTimestampOffset` flag value in order to disable caching for data with timestamps close to the current time. Single-node VictoriaMetrics automatically resets response diff --git a/docs/Single-server-VictoriaMetrics.md b/docs/Single-server-VictoriaMetrics.md index e45d0c71d..76d4ab5b1 100644 --- a/docs/Single-server-VictoriaMetrics.md +++ b/docs/Single-server-VictoriaMetrics.md @@ -2321,6 +2321,21 @@ Sometimes it is needed to remove such caches on the next startup. This can be do In this case VictoriaMetrics will automatically remove all the caches on the next start. See [this issue](https://github.com/VictoriaMetrics/VictoriaMetrics/issues/1447) for details. +It is also possible removing [rollup result cache](#rollup-result-cache) on startup by passing `-search.resetRollupResultCacheOnStartup` command-line flag to VictoriaMetrics. + +## Rollup result cache + +VictoriaMetrics caches query reponses by default. This allows increasing performance for repated queries +to [`/api/v1/query`](https://docs.victoriametrics.com/keyconcepts/#instant-query) and [`/api/v1/query_range`](https://docs.victoriametrics.com/keyconcepts/#range-query) +with the increasing `time`, `start` and `end` query args. + +This cache may work incorrectly when ingesting historical data into VictoriaMetrics. See [these docs](#backfilling) for details. + +The rollup cache can be disabled either globally by running VictoriaMetrics with `-search.disableCache` command-line flag +or on a per-query basis by passing `nocache=1` query arg to `/api/v1/query` and `/api/v1/query_range`. + +See also [cache removal docs](#cache-removal). + ## Cache tuning VictoriaMetrics uses various in-memory caches for faster data ingestion and query performance. @@ -2385,11 +2400,12 @@ VictoriaMetrics accepts historical data in arbitrary order of time via [any supp See [how to backfill data with recording rules in vmalert](https://docs.victoriametrics.com/vmalert.html#rules-backfilling). Make sure that configured `-retentionPeriod` covers timestamps for the backfilled data. -It is recommended disabling query cache with `-search.disableCache` command-line flag when writing +It is recommended disabling [query cache](#rollup-result-cache) with `-search.disableCache` command-line flag when writing historical data with timestamps from the past, since the cache assumes that the data is written with the current timestamps. Query cache can be enabled after the backfilling is complete. -An alternative solution is to query [/internal/resetRollupResultCache](https://docs.victoriametrics.com/url-examples.html#internalresetrollupresultcache) handler after the backfilling is complete. This will reset the query cache, which could contain incomplete data cached during the backfilling. +An alternative solution is to query [/internal/resetRollupResultCache](https://docs.victoriametrics.com/url-examples.html#internalresetrollupresultcache) +after the backfilling is complete. This will reset the [query cache](#rollup-result-cache), which could contain incomplete data cached during the backfilling. Yet another solution is to increase `-search.cacheTimestampOffset` flag value in order to disable caching for data with timestamps close to the current time. Single-node VictoriaMetrics automatically resets response