单节点VictoriaMetrics百万级写入关键在于使用/write端点+InfluxDB行协议：/api/v1/import/prometheus因需解析文本格式导致CPU飙升，而/write支持零拷贝二进制写入，延迟稳定。
单节点 VictoriaMetrics 在 32 核 64GB 内存机器上稳定处理每秒百万级指标写入，关键不在“堆资源”，而在关闭干扰项、绕过文本解析、让数据走最短路径——/write 端点 + InfluxDB 行协议是唯一经生产验证的低开销通路。
必须用 /write 端点，别碰 /api/v1/import/prometheus
Prometheus 文本格式写入需要逐行解析 HELP/TYPE 注释、标签键值对、浮点数和时间戳，CPU 消耗高且无法批量压缩。实测在 10 万点/秒时 CPU 占用已达 40%+，到百万级必然卡在解析阶段。
-
/write是二进制友好的行协议端点，VictoriaMetrics 对其做了零拷贝优化，写入延迟稳定在 - 所有 Telegraf、InfluxDB v1.x 客户端、自研上报 SDK 都原生支持该协议，无需改造数据结构
- 避免使用
remote_write到单节点 VM：Prometheus 的 remote_write 默认带重试队列与序列化封装，多一层 GC 和缓冲，资源浪费明显
关掉流式聚合（-streamAggr.disable）和样本保留逻辑
流式聚合默认开启时，每个匹配规则都会在内存中维护一个聚合状态机（如 sum 计数器或 histogram_quantile 分位桶），即使没配规则，VM 仍会做轻量路由判断。百万级时间序列下，这部分内存和 GC 压力不可忽视。
- 明确加启动参数
-streamAggr.disable，彻底跳过 stream-aggr 模块初始化 - 若需降采样，改用 vmagent 的
stream_aggr功能（部署在写入链路前端），让 VictoriaMetrics 单节点只干一件事：存 - 禁用原始样本保留：
-streamAggr.keepInput=false -streamAggr.dropInput=true（如果已启用流式聚合）
调大写入缓冲与禁用 WAL 同步（仅限单节点 + 本地盘场景）
VictoriaMetrics 默认启用 WAL（Write-Ahead Log）保障 crash-safe，但每次写入都触发 fsync，在高吞吐下成为 I/O 瓶颈。若你接受极小概率（进程崩溃但未 kill -9）丢失最近几秒数据，可安全放宽。
- 加大内存缓冲：
-insert.maxQueueDuration=30s（默认 10s），允许更多样本攒批写入 SSTable - 关闭强制同步：
-storage.disableWAL，配合-memory.allowedPercent=75控制内存水位，实测写入吞吐提升 2.3 倍 - 注意：此组合仅适用于单节点 + 本地 NVMe 盘；集群版或网络存储（NFS/EBS）严禁关闭 WAL
标签爆炸前必须做预过滤或重打标签
真正压垮 VM 的从来不是“点数”，而是“时间序列数”。一个带 pod_name="pod-xyz-abc-123" 的指标，在 1000 个 Pod 里每秒各报一次，就生成 1000 条独立时间序列 —— 这就是高基数搅动。VM 的索引构建和 LSM merge 成本随序列数非线性上升。
- 在 vmagent 层用
drop或labeldrop干掉无业务意义的标签（如container_id,host_ip） - 用
labelmap将动态值聚合成静态分类，例如把pod_name="web-01"→service="web" - 避免在写入时动态拼接标签（如
path="/user/:id"），这类 label 值实际是无限集，必须前置归一化
资源占用低的本质，是让 VictoriaMetrics 回归“时序存储”本职：不解析、不聚合、不路由、不重试。所有预处理移出核心链路，写入路径越直，吞吐越高，内存越稳。一旦开始在单节点上加规则、加租户、加远程读代理，它就不再是那个百万写入的轻量选手了。
