直接用官方预编译二进制包（如victoria-metrics-v1.125.1-linux-amd64.tar.gz）部署victoria-metrics-prod，配-storageDataPath（本地SSD路径且属主为vmuser）、-retentionPeriod（单位须为d或m），并配置systemd三要素：LimitNOFILE=65536、User=vmuser、ExecStart中路径权限正确，即可稳定运行。
直接用官方预编译二进制部署 victoria-metrics-prod，配对 -storageDataPath 和 -retentionPeriod，再加 systemd 三要素（User、LimitNOFILE、ExecStart 中路径所有权），就能稳定压到 Prometheus 20% 内存占用——不是靠调参“省”，而是它根本不用 WAL、不存 label 副本、列式压缩天然低开销。
怎么选对二进制包，避免启动就报错
GitHub Releases 页面只认 victoria-metrics-v*.tar.gz（比如 victoria-metrics-v1.125.1-linux-amd64.tar.gz），别下 -src.zip，更别单独下载 victoria-metrics-prod 文件——后者是企业版，启动必报 failed to parse license。解压后只留一个可执行文件：victoria-metrics-prod。运行 file victoria-metrics-prod 必须输出含 statically linked，说明它不依赖系统 libc；再跑 ./victoria-metrics-prod -version 能打出版本号，才算真正可用。
systemd 服务必须写的三项硬配置
裸跑 nohup ./victoria-metrics-prod & 只能临时验证，生产环境必须用 systemd 托管，否则进程容易被 OOM kill 或静默退出。
-
LimitNOFILE=65536：systemd 默认限制 1024，VictoriaMetrics 高并发下很快耗尽，不加这一行，journalctl -u victoriametrics里全是accept: too many open files -
User=vmuser和Group=vmuser：必须创建无登录 shell 的专用用户，命令是useradd -r -s /bin/false vmuser -
ExecStart中指定的-storageDataPath目录，必须由vmuser拥有，且不能是/tmp、/var/tmp或 NFS 路径（SELinux 会拦截 mmap）
-storageDataPath 和 -retentionPeriod 配错会导致数据无声丢失
这两个参数看似简单，但配错后果最严重，且不易察觉：
-
-storageDataPath=/data/vm：路径必须是本地 SSD，HDD 上开启-retentionPeriod=12m会导致 compaction 延迟飙升，查询变卡；目录权限执行chown vmuser:vmuser /data/vm -
-retentionPeriod=365d：单节点长期存储必须显式设，不设默认只保留 1 个月；注意单位是d（天）或m（月），写成365会被当秒处理，数据几秒后就清空 - 别碰
-memory.allowedPercent：VM 不像 Prometheus 那样靠内存限流，强行设低反而触发频繁刷盘，写入延迟翻倍
Prometheus 远程写入配置要改两处
要让 Prometheus 把数据吐给 VictoriaMetrics，不是只改 remote_write.url 就完事：
-
remote_write.url改成"http://vm-host:8428/api/v1/write"（注意端口是8428，不是9090） - 必须加
queue_config.max_samples_per_send: 10000：默认 100 太小，批量太碎，网络和 VM 解析开销暴增；实测调到 10000 后，同样指标量下 CPU 降 40% - 删掉
write_relabel_configs里所有drop或keep：VM 标签索引机制和 Prometheus 不同，误删标签会导致后续查不到数据
真正卡点不在安装，而在 storageDataPath 目录是否落在本地 SSD、vmuser 是否真拥有该目录、以及 retentionPeriod 单位有没有写错——这三个地方任意一个漏掉，VM 就会退化成“高延迟+高丢数”的假轻量状态。
