VictoriaMetrics 中文教程（06）容量规划

VictoriaMetrics

VictoriaMetrics 中文教程系列文章：

核心摘要

VictoriaMetrics 容量规划不能只套固定公式，CPU 和 RAM 需求高度依赖活动时间序列数量、序列流失率、查询类型、查询 QPS 等工作负载。
推荐做法是在生产工作负载上搭建测试 VictoriaMetrics，逐步扩大压力以及 CPU/RAM 资源，直到系统稳定。
存储空间可以通过短期测试运行估算：例如一天产生 10GB 数据，-retentionPeriod=100d 至少需要约 1TB 存储。
建议保留 50% 可用 RAM、50% 备用 CPU，以及 -storageDataPath 目录中至少 20% 可用存储空间。
资源限制参数主要用于控制查询内存、并发、持续时间、扫描序列数量、返回序列数量和高基数场景下的 API 压力。

VictoriaMetrics 容量规划

根据 VictoriaMetrics 的案例研究，与竞争解决方案 Prometheus、Thanos、Cortex、TimescaleDB、InfluxDB、QuestDB、M3DB 相比，VictoriaMetrics 在生产工作负载上使用的 CPU、RAM 和存储空间更少。

VictoriaMetrics 的容量随可用资源呈线性扩展。但所需 CPU 和 RAM 数量高度依赖工作负载，包括：

活动时间序列数量。
时间序列流失率。
查询类型。
查询 QPS。

建议为生产工作负载搭建测试 VictoriaMetrics，逐步扩大压力以及 CPU、RAM 资源，直到系统变得稳定。通过生产环境的部分负载测试，可以了解 VictoriaMetrics 在自己环境中的性能和资源需求。

根据案例研究，单节点 VictoriaMetrics 可以处理以下生产工作负载：

采集率：每秒 150 万个样本。
活跃时间序列：5000 多万。
总时间序列：50 多亿。
时间序列流失率：每天有 1.5 亿个新序列。
样本总数：10+ 万亿。
查询：200+ QPS。
查询延迟，第 99 百分位：1 秒。

这些数据可以作为理解 VictoriaMetrics 能力边界的参考，但自己的容量规划仍然要以实际工作负载测试为准。

如何估算存储空间

可以根据测试运行中的磁盘空间使用情况，推断给定保留时间所需的存储空间。保留时间通过 -retentionPeriod 命令行参数设置。

例如，如果在生产工作负载上测试运行一天后，-storageDataPath 目录大小变为 10GB，那么 -retentionPeriod=100d，也就是保留 100 天，至少需要：

10GB * 100 = 1TB

这个估算方法很朴素，但很实用。先接入一部分真实数据，运行一天，观察磁盘增长，再按目标保留时间线性放大。

建议保留的备用资源

容量规划不能刚好卡满资源，否则工作负载临时激增时很容易出问题。建议保留以下备用资源：

50% 可用 RAM，用于降低工作负载暂时激增期间发生 OOM 和变慢的概率。
50% 备用 CPU，用于降低工作负载暂时激增时变慢的概率。
-storageDataPath 命令行参数指向的目录中至少保留 20% 可用存储空间。

VictoriaMetrics 资源限制参数

默认情况下，VictoriaMetrics 针对典型工作负载已经给出了默认配置。某些工作负载可能需要更细粒度的资源使用限制，这时下面这些命令行参数会有帮助。

内存限制

-memory.allowedPercent 和 -memory.allowedBytes：限制 VictoriaMetrics 各种内部缓存可使用的内存量。注意，VictoriaMetrics 可能使用更多内存，因为这些参数不会限制每个查询可能需要的额外内存。
-search.maxMemoryPerQuery：限制处理单个查询可使用的内存量。需要更多内存的查询会被拒绝。选择大量时间序列的繁重查询可能会略微超出每查询内存限制。并发查询总内存限制可以估算为 -search.maxMemoryPerQuery 乘以 -search.maxConcurrentRequests。

单查询规模和持续时间限制

-search.maxUniqueTimeseries：限制单个查询可以查找和处理的唯一时间序列数量。默认情况下，VictoriaMetrics 会根据可用内存和最大并发请求数自动计算限制。VictoriaMetrics 会在内存中保存每个查询找到的时间序列元信息，并消耗 CPU 处理这些序列。因此，单查询最大内存使用量和 CPU 使用量与该参数成正比。
-search.maxQueryDuration：限制单个查询持续时间。查询超过给定持续时间会被取消，可以在执行意外繁重查询时节省 CPU 和 RAM。每个查询可通过 timeout GET 参数更改限制，但不能超过命令行参数指定的上限。
-search.maxSamplesPerSeries：限制查询可以处理的每条时间序列原始样本数量。VictoriaMetrics 查询时会按顺序处理找到的每条时间序列原始样本，把选定时间范围内的原始样本解压到内存中，再应用汇总函数。
-search.maxSamplesPerQuery：限制单个查询可以处理的原始样本数量，用于限制繁重查询的 CPU 使用。

并发和排队限制

-search.maxConcurrentRequests：限制 VictoriaMetrics 可处理的并发请求数。并发请求越多，通常内存使用越高。例如，单个查询执行期间需要 100MiB 额外内存时，100 个并发查询可能需要 10GiB 额外内存。因此最好限制并发查询数，并在达到限制时暂停其他传入查询。
-search.maxQueueDuration：限制达到 -search.maxConcurrentRequests 后，查询等待执行的最长时间。

返回结果规模限制

-search.maxResponseSeries：限制单个查询可以从 /api/v1/query 和 /api/v1/query_range 返回的时间序列数量。
-search.maxPointsPerTimeseries：限制范围查询中每个匹配时间序列可返回的计算点数量。
-search.maxPointsSubqueryPerTimeseries：限制子查询评估期间每个匹配时间序列可以生成的计算点数量。
-search.maxSeriesPerAggrFunc：限制 MetricsQL 聚合函数在单个查询中可以生成的时间序列数量。

Labels API、Series API 和高基数场景限制

-search.maxSeries：限制 /api/v1/series 返回的时间序列数量。这个端点主要由 Grafana 用于自动完成指标名称、标签名称和标签值。当数据库包含大量唯一时间序列时，高流失率会让这些查询占用大量 CPU 和内存。此时可以设置较低值。
-search.maxTagKeys：限制 /api/v1/labels 返回的项目数量。该端点主要由 Grafana 用于自动完成标签名称。
-search.maxTagValues：限制 /api/v1/label/…/values 返回的项目数量。该端点主要由 Grafana 用于自动完成标签值。
-search.maxLabelsAPISeries：限制执行 /api/v1/labels、/api/v1/label/…/values 或 /api/v1/series 请求时可以扫描的时间序列数量。
-search.maxLabelsAPIDuration：限制对 /api/v1/labels、/api/v1/label/…/values 或 /api/v1/series 的请求持续时间。每个查询可以通过 timeout GET 参数更改限制，但不能超过命令行参数指定的上限。
-search.ignoreExtraFiltersAtLabelsAPI：允许忽略 /api/v1/labels 和 /api/v1/label/…/values 中的 match[]、extra_filters[] 和 extra_label 查询参数。如果额外过滤器匹配太多时间序列，这可能有助于减少 VictoriaMetrics 负载。缺点是端点可能返回与额外过滤器不匹配的标签和序列。

删除和 Graphite API 限制

-search.maxDeleteSeries：限制单个 /api/v1/admin/tsdb/delete_series 调用可以删除的唯一时间序列数量。删除过多时间序列可能需要大量 CPU 和内存，这个限制可以防止计划外资源使用激增。
-search.maxTagValueSuffixesPerSearch：限制 /metrics/find 端点返回的条目数。可参考 Graphite Metrics API 使用文档。

参数选择思路

这些参数很多，不建议一上来全部配置。更实际的顺序是：

先用默认配置跑起来。
接入一部分真实生产负载，观察 CPU、RAM、磁盘增长和查询延迟。
根据问题类型调参：内存不稳先看单查询和并发限制；Grafana 自动完成拖慢系统时看 Labels API 和 Series API 限制；删除操作风险高时看删除限制。
每次只调整少量参数，并记录调整前后的指标变化。

FAQ

VictoriaMetrics 容量规划有没有通用公式？

没有一个适合所有场景的固定公式。CPU 和 RAM 需求高度依赖活动时间序列、序列流失率、查询类型和查询 QPS。最可靠的方法是用真实负载测试，再按保留时间和增长趋势估算。

存储空间怎么估算最简单？

先接入真实工作负载跑一天，观察 -storageDataPath 目录增长。例如一天增长 10GB，保留 100 天就至少准备约 1TB，再额外保留 20% 以上可用空间。

什么时候需要配置资源限制参数？

默认配置适合典型工作负载。只有在出现查询过重、并发过高、Grafana 自动完成拖慢系统、高基数 API 压力大、删除操作风险高等问题时，才需要针对性配置。

总结

VictoriaMetrics 是一个高性能、低资源消耗的时序数据库，可以替代 Prometheus 存储，用于高可用和持久化。容量规划的核心思路是：先运行一段时间，接入少量真实数据，运行一天后再对全量数据做估算。本文同时整理了 VictoriaMetrics 应对大规模场景的资源限制参数，实际使用时建议从默认配置开始，按问题类型逐步调整。