From 55bd43f28e7c90c9b47b381e66a6faa008bc9de9 Mon Sep 17 00:00:00 2001 From: Aliaksandr Valialkin Date: Tue, 2 Apr 2024 23:57:35 +0300 Subject: [PATCH] docs: follow-up for ac9c2a796fcabe39a476b5194d016d1bb482b943 Remove description for -search.maxExportDuration and -search.maxStatusRequestDuration command-line flags from the 'Resource usage limits' chapter, since these flags are rarely used for limiting resource usage and they are already documented in the 'List of command-line flags' chapter. --- README.md | 10 +--------- docs/Cluster-VictoriaMetrics.md | 10 +--------- docs/README.md | 10 +--------- docs/Single-server-VictoriaMetrics.md | 13 +------------ 4 files changed, 4 insertions(+), 39 deletions(-) diff --git a/README.md b/README.md index 52c4bd0aa..73e1ce9c7 100644 --- a/README.md +++ b/README.md @@ -1681,7 +1681,7 @@ By default, VictoriaMetrics is tuned for an optimal resource usage under typical This means that the maximum memory usage and CPU usage a single query can use is proportional to `-search.maxUniqueTimeseries`. - `-search.maxQueryDuration` limits the duration of a single query. If the query takes longer than the given duration, then it is canceled. This allows saving CPU and RAM when executing unexpected heavy queries. - The limit can be altered for each query by passing `timeout` GET parameter, but can't exceed the limit specified via cmd-line flag. + The limit can be altered for each query by passing `timeout` GET parameter, but can't exceed the limit specified via `-search.maxQueryDuration` command-line flag. - `-search.maxConcurrentRequests` limits the number of concurrent requests VictoriaMetrics can process. Bigger number of concurrent requests usually means bigger memory usage. For example, if a single query needs 100 MiB of additional memory during its execution, then 100 concurrent queries may need `100 * 100 MiB = 10 GiB` of additional memory. So it is better to limit the number of concurrent queries, while pausing additional incoming queries if the concurrency limit is reached. @@ -1735,14 +1735,6 @@ By default, VictoriaMetrics is tuned for an optimal resource usage under typical when the database contains big number of unique time series because of [high churn rate](https://docs.victoriametrics.com/FAQ.html#what-is-high-churn-rate). In this case it might be useful to set the `-search.maxLabelsAPIDuration` to quite low value in order to limit CPU and memory usage. See also `-search.maxLabelsAPISeries` and `-search.ignoreExtraFiltersAtLabelsAPI`. -- `-search.maxExportDuration` limits the duration for requests to [/api/v1/export*](https://docs.victoriametrics.com/url-examples/?highlight=apiv1export#apiv1export). - If the query takes longer than the given duration, then it is canceled. - This allows saving CPU and RAM when executing unexpectedly heavy queries. - The limit can be altered for each query by passing `timeout` GET parameter, but can't exceed the limit specified via cmd-line flag. -- `search.maxStatusRequestDuration` limits the duration for requests to [/api/v1/status/tsdb](https://docs.victoriametrics.com/url-examples/?highlight=apiv1export#apiv1statustsdb). - If the query takes longer than the given duration, then it is canceled. - This allows saving CPU and RAM when executing unexpectedly heavy queries. - The limit can be altered for each query by passing `timeout` GET parameter, but can't exceed the limit specified via cmd-line flag. - `-search.maxTagValueSuffixesPerSearch` limits the number of entries, which may be returned from `/metrics/find` endpoint. See [Graphite Metrics API usage docs](#graphite-metrics-api-usage). See also [resource usage limits at VictoriaMetrics cluster](https://docs.victoriametrics.com/Cluster-VictoriaMetrics.html#resource-usage-limits), diff --git a/docs/Cluster-VictoriaMetrics.md b/docs/Cluster-VictoriaMetrics.md index fba8b5a2f..aa20b365e 100644 --- a/docs/Cluster-VictoriaMetrics.md +++ b/docs/Cluster-VictoriaMetrics.md @@ -654,7 +654,7 @@ Some workloads may need fine-grained resource usage limits. In these cases the f a single query can use at `vmstorage` is proportional to `-search.maxUniqueTimeseries`. - `-search.maxQueryDuration` at `vmselect` limits the duration of a single query. If the query takes longer than the given duration, then it is canceled. This allows saving CPU and RAM at `vmselect` and `vmstorage` when executing unexpectedly heavy queries. - The limit can be altered for each query by passing `timeout` GET parameter, but can't exceed the limit specified via cmd-line flag. + The limit can be altered for each query by passing `timeout` GET parameter, but can't exceed the limit specified via `-search.maxQueryDuration` command-line flag. - `-search.maxConcurrentRequests` at `vmselect` and `vmstorage` limits the number of concurrent requests a single `vmselect` / `vmstorage` node can process. Bigger number of concurrent requests usually require bigger amounts of memory at both `vmselect` and `vmstorage`. For example, if a single query needs 100 MiB of additional memory during its execution, then 100 concurrent queries @@ -716,14 +716,6 @@ Some workloads may need fine-grained resource usage limits. In these cases the f when the database contains big number of unique time series because of [high churn rate](https://docs.victoriametrics.com/FAQ.html#what-is-high-churn-rate). In this case it might be useful to set the `-search.maxLabelsAPIDuration` to quite low value in order to limit CPU and memory usage. See also `-search.maxLabelsAPISeries` and `-search.ignoreExtraFiltersAtLabelsAPI`. -- `-search.maxExportDuration` at `vmselect` limits the duration for requests to [/api/v1/export*](https://docs.victoriametrics.com/url-examples/?highlight=apiv1export#apiv1export). - If the query takes longer than the given duration, then it is canceled. - This allows saving CPU and RAM at `vmselect` and `vmstorage` when executing unexpectedly heavy queries. - The limit can be altered for each query by passing `timeout` GET parameter, but can't exceed the limit specified via cmd-line flag. -- `search.maxStatusRequestDuration` at `vmselect` limits the duration for requests to [/api/v1/status/tsdb](https://docs.victoriametrics.com/url-examples/?highlight=apiv1export#apiv1statustsdb). - If the query takes longer than the given duration, then it is canceled. - This allows saving CPU and RAM at `vmselect` and `vmstorage` when executing unexpectedly heavy queries. - The limit can be altered for each query by passing `timeout` GET parameter, but can't exceed the limit specified via cmd-line flag. - `-storage.maxDailySeries` at `vmstorage` can be used for limiting the number of time series seen per day aka [time series churn rate](https://docs.victoriametrics.com/FAQ.html#what-is-high-churn-rate). See [cardinality limiter docs](#cardinality-limiter). - `-storage.maxHourlySeries` at `vmstorage` can be used for limiting the number of [active time series](https://docs.victoriametrics.com/FAQ.html#what-is-an-active-time-series). diff --git a/docs/README.md b/docs/README.md index ae4956760..93e21b29f 100644 --- a/docs/README.md +++ b/docs/README.md @@ -1684,7 +1684,7 @@ By default, VictoriaMetrics is tuned for an optimal resource usage under typical This means that the maximum memory usage and CPU usage a single query can use is proportional to `-search.maxUniqueTimeseries`. - `-search.maxQueryDuration` limits the duration of a single query. If the query takes longer than the given duration, then it is canceled. This allows saving CPU and RAM when executing unexpected heavy queries. - The limit can be altered for each query by passing `timeout` GET parameter, but can't exceed the limit specified via cmd-line flag. + The limit can be altered for each query by passing `timeout` GET parameter, but can't exceed the limit specified via `-search.maxQueryDuration` command-line flag. - `-search.maxConcurrentRequests` limits the number of concurrent requests VictoriaMetrics can process. Bigger number of concurrent requests usually means bigger memory usage. For example, if a single query needs 100 MiB of additional memory during its execution, then 100 concurrent queries may need `100 * 100 MiB = 10 GiB` of additional memory. So it is better to limit the number of concurrent queries, while pausing additional incoming queries if the concurrency limit is reached. @@ -1738,14 +1738,6 @@ By default, VictoriaMetrics is tuned for an optimal resource usage under typical when the database contains big number of unique time series because of [high churn rate](https://docs.victoriametrics.com/FAQ.html#what-is-high-churn-rate). In this case it might be useful to set the `-search.maxLabelsAPIDuration` to quite low value in order to limit CPU and memory usage. See also `-search.maxLabelsAPISeries` and `-search.ignoreExtraFiltersAtLabelsAPI`. -- `-search.maxExportDuration` limits the duration for requests to [/api/v1/export*](https://docs.victoriametrics.com/url-examples/?highlight=apiv1export#apiv1export). - If the query takes longer than the given duration, then it is canceled. - This allows saving CPU and RAM when executing unexpectedly heavy queries. - The limit can be altered for each query by passing `timeout` GET parameter, but can't exceed the limit specified via cmd-line flag. -- `search.maxStatusRequestDuration` limits the duration for requests to [/api/v1/status/tsdb](https://docs.victoriametrics.com/url-examples/?highlight=apiv1export#apiv1statustsdb). - If the query takes longer than the given duration, then it is canceled. - This allows saving CPU and RAM when executing unexpectedly heavy queries. - The limit can be altered for each query by passing `timeout` GET parameter, but can't exceed the limit specified via cmd-line flag. - `-search.maxTagValueSuffixesPerSearch` limits the number of entries, which may be returned from `/metrics/find` endpoint. See [Graphite Metrics API usage docs](#graphite-metrics-api-usage). See also [resource usage limits at VictoriaMetrics cluster](https://docs.victoriametrics.com/Cluster-VictoriaMetrics.html#resource-usage-limits), diff --git a/docs/Single-server-VictoriaMetrics.md b/docs/Single-server-VictoriaMetrics.md index 886fbb671..4f01dfd32 100644 --- a/docs/Single-server-VictoriaMetrics.md +++ b/docs/Single-server-VictoriaMetrics.md @@ -1557,9 +1557,6 @@ VictoriaMetrics supports data ingestion via [OpenTelemetry protocol for metrics] VictoriaMetrics expects `protobuf`-encoded requests at `/opentelemetry/v1/metrics`. Set HTTP request header `Content-Encoding: gzip` when sending gzip-compressed data to `/opentelemetry/v1/metrics`. -VictoriaMetrics automatically does not sanitize metric names for the data ingested via OpenTelemetry protocol -If you need accepting metric and label names as is with sanitizing, then pass `-opentelemetry.sanitizeMetrics=true` command-line flag to VictoriaMetrics. - See [How to use OpenTelemetry metrics with VictoriaMetrics](https://docs.victoriametrics.com/guides/getting-started-with-opentelemetry/). ## JSON line format @@ -1695,7 +1692,7 @@ By default, VictoriaMetrics is tuned for an optimal resource usage under typical This means that the maximum memory usage and CPU usage a single query can use is proportional to `-search.maxUniqueTimeseries`. - `-search.maxQueryDuration` limits the duration of a single query. If the query takes longer than the given duration, then it is canceled. This allows saving CPU and RAM when executing unexpected heavy queries. - The limit can be altered for each query by passing `timeout` GET parameter, but can't exceed the limit specified via cmd-line flag. + The limit can be altered for each query by passing `timeout` GET parameter, but can't exceed the limit specified via `-search.maxQueryDuration` command-line flag. - `-search.maxConcurrentRequests` limits the number of concurrent requests VictoriaMetrics can process. Bigger number of concurrent requests usually means bigger memory usage. For example, if a single query needs 100 MiB of additional memory during its execution, then 100 concurrent queries may need `100 * 100 MiB = 10 GiB` of additional memory. So it is better to limit the number of concurrent queries, while pausing additional incoming queries if the concurrency limit is reached. @@ -1749,14 +1746,6 @@ By default, VictoriaMetrics is tuned for an optimal resource usage under typical when the database contains big number of unique time series because of [high churn rate](https://docs.victoriametrics.com/FAQ.html#what-is-high-churn-rate). In this case it might be useful to set the `-search.maxLabelsAPIDuration` to quite low value in order to limit CPU and memory usage. See also `-search.maxLabelsAPISeries` and `-search.ignoreExtraFiltersAtLabelsAPI`. -- `-search.maxExportDuration` limits the duration for requests to [/api/v1/export*](https://docs.victoriametrics.com/url-examples/?highlight=apiv1export#apiv1export). - If the query takes longer than the given duration, then it is canceled. - This allows saving CPU and RAM when executing unexpectedly heavy queries. - The limit can be altered for each query by passing `timeout` GET parameter, but can't exceed the limit specified via cmd-line flag. -- `search.maxStatusRequestDuration` limits the duration for requests to [/api/v1/status/tsdb](https://docs.victoriametrics.com/url-examples/?highlight=apiv1export#apiv1statustsdb). - If the query takes longer than the given duration, then it is canceled. - This allows saving CPU and RAM when executing unexpectedly heavy queries. - The limit can be altered for each query by passing `timeout` GET parameter, but can't exceed the limit specified via cmd-line flag. - `-search.maxTagValueSuffixesPerSearch` limits the number of entries, which may be returned from `/metrics/find` endpoint. See [Graphite Metrics API usage docs](#graphite-metrics-api-usage). See also [resource usage limits at VictoriaMetrics cluster](https://docs.victoriametrics.com/Cluster-VictoriaMetrics.html#resource-usage-limits),