编码预计 55 分钟

性能调优实战

带着 flamegraph 和 perf 做一轮完整调优:找热点、改一处、量化收益、防止回退 —— 目标是把 L4 验收时的性能再抬 30%。

学完这节你能做到

用 perf / flamegraph 定位 CPU 与延迟热点
完成三处有数据支撑的优化
建立性能回归测试防止优化被吃掉

调优不是玄学,是审计

你见过太多「玄学调优」:改个内核参数拜一拜,快了 5% 就写进总结,慢了就当没发生 —— 下次换台机器全部失效。也见过反面教材:有人把某个参数从默认值改到「网上说好」的值, 半年后一次故障排查才发现它一直在拖后腿。

研发侧的调优纪律只有一条,但要焊死:每一处优化 = 一个基线 + 一个假设 + 一次测量 + 一个结论。没有基线的优化都是玄学,没有假设的测量都是乱枪。这节课带着这条纪律做一轮完整调优, 目标写死:在 L4 里程碑验收的性能数据之上,吞吐或 IOPS 再提 30%,由三处有数据支撑的优化构成, 每一处都要能写进报告:改了什么、为什么、快了多少。

建基线:先钉死度量

工具就是 L2 造的 forge-bench —— 当时它是验收工具,现在升格成调优的标尺。先钉死口径,不然「提升 30%」无从谈起:

# 基线负载,固定三种,覆盖数据面和元数据面
forge-bench --profile 4k-randwrite  --qd 64 --duration 120s --warmup 20s
forge-bench --profile 1m-seqwrite   --qd 8  --duration 120s --warmup 20s
forge-bench --profile meta-create   --dirs 64 --files 100000

# 每种跑 5 遍,记录中位数和波动范围,存档为 baseline-l4.json

三条口径纪律,全是你做压测评审时挑过别人的刺:

预热要够:page cache、连接池、Raft leader 稳定之前的数据全丢弃
跑多遍看波动:单次结果波动 ±8% 的环境里,「提升 5%」是噪声不是优化
环境钉死:CPU governor 设 performance、关 turbo 波动、固定测试盘 —— 记进报告,别人才能复现

L4 验收时假设的数据是:4k 随机写 41k IOPS、1M 顺序写 2.1 GB/s、创建 9k ops/s。这就是我们要抬 30% 的起点。

找热点:flamegraph 与 perf

猜瓶颈的命中率低得惊人 —— 作者本人猜自己系统的热点,业界经验也就三成命中。所以先测量,后动手:

# 火焰图:一条命令,负载压着的同时采样
cargo flamegraph --profile release-debug -p forge-node -- --config node0.toml
# release-debug profile: 开优化但保留调试符号,否则火焰图全是问号

# perf 看更细的:哪条指令、多少缓存缺失、多少上下文切换
perf stat -p $(pgrep forge-node) -- sleep 30
perf record -g -p $(pgrep forge-node) -- sleep 30 && perf report

打开火焰图,横轴是采样占比,越宽越热。存储系统里的惯犯就四类, 一个个对着 forge 的火焰图找:

拷贝:memcpy 的宽塔。数据从 FUSE buffer 到条带 buffer 到 RPC body 到落盘 buffer, 每复制一次都是白烧的内存带宽 —— 4k 写复制 4 次,等于带宽打了 2.5 折
分配:malloc/free 塔。热路径上每请求 new 一个 Vec 或 BytesMut, 高 QPS 下分配器本身成为热点
锁:futex 相关调用,或者火焰图上看不出来但 P99 很难看 —— 锁竞争烧的常常不是 CPU 而是延迟,配合 perf sched 或 tokio-console 看任务等待
系统调用:write/fsync 的塔一根根立着。每次调用固定开销 1~2μs, 小 IO 一个个提交就是拿系统调用开销除以 4k 的数据量

iP99 热点和 CPU 热点不是一回事

火焰图找的是 CPU 时间去哪了,但你被折磨过的 P99 毛刺常常不烧 CPU: fsync 被别人排队、锁被长临界区占住、tokio worker 被一个同步调用堵死。查毛刺要换武器 —— 上一课的慢 IO 日志和 span 树,正是为此准备的。两张图对照看:CPU 火焰图管吞吐,span 瀑布管长尾。

三处优化:批量化与零拷贝

对着火焰图,forge 的三刀这样下(你的火焰图可能不同,方法一致):

第一刀:WAL group commit 真正批起来。 火焰图显示 fsync 塔占了写路径 30% 的墙上时间。 L1 写 group commit 时用的是固定 5ms 窗口攒批 —— 低负载白等 5ms,高负载攒不满。改成自适应:有请求在排队就立即刷,刷盘期间到达的请求自然攒成下一批:

// 改造前:sleep(5ms) 攒批 —— 低负载平白多 5ms 延迟
// 改造后:leader-based 提交,fsync 由当前批的 leader 执行,期间到达者入下一批
async fn commit(&self, rec: Record) -> Result<Lsn, WalError> {
    let ticket = self.queue.push(rec)?;
    if self.flush_lock.try_acquire() {
        // 我是 leader:把队列里现有的全部记录一次写入 + 一次 fsync
        self.flush_batch().await?;
    }
    ticket.wait_durable().await   // follower 只等通知,不重复 fsync
}

实测:4k 随机写 41k → 52k IOPS(+27%),P50 延迟 1.4ms → 0.9ms。一刀就接近目标的大头。

第二刀:写路径零拷贝。 memcpy 塔占 CPU 12%。把写路径的 buffer 统一换成 bytes::Bytes:FUSE 收到数据后只做一次拷贝进引用计数 buffer, 之后条带切分用 slice()(只调整指针不复制),tonic 发送和落盘共享同一份底层内存。 EC 编码必须真算,但编码输出直接写进落盘对齐的 buffer,省掉中转。实测:1M 顺序写 2.1 → 2.6 GB/s(+24%),节点 CPU 占用从 71% 降到 58%。

第三刀:元数据热锁拆分。 meta-create 压测时火焰图很平但扩不上去, tokio-console 显示任务大量等待同一把 inode 分配锁。把全局分配锁换成每分片一个原子计数段(每次批发 1024 个 inode 号),竞争消失。实测:创建 9k → 13k ops/s(+44%)。

三刀汇总回归基线:4k 随机写 +27%、顺序写 +24%、创建 +44% —— 达标, 且每一条都有 before/after 数据和火焰图存档。这就是「有数据支撑」的含义。

Checkpoint单选

同事说「我把这个 Vec 换成了预分配,系统应该快了」。按本课的纪律,这句话缺什么?

性能回归 CI:守住胜利果实

调优最气人的结局你见过:辛苦抬上去的性能,三个月后被一个「顺手的小重构」悄悄吃回去, 没人发现,直到用户投诉。防御方案分两层:

微观层用 criterion:对热点函数(EC 编码、crc、extent 分配)建 benchmark, criterion 自带统计检验,能区分真回退和噪声:

fn bench_ec_encode(c: &mut Criterion) {
    let data = vec![0u8; 4 * 1024 * 1024];
    let codec = EcCodec::new(4, 2).expect("valid ec config");
    c.bench_function("ec_encode_4m", |b| {
        b.iter(|| codec.encode(black_box(&data)))
    });
}

宏观层用 forge-bench:CI 里每个 PR 跑一轮缩短版基线(30s 一种负载), 和主干最近的存档结果比,任一指标退步超过 5% 就把 PR 标红。两个运维常识要带进来:CI 机器性能有波动,所以阈值给 5% 而不是 1%; 标红是「要求解释」不是「禁止合并」—— 有些回退是功能换的,值得,但必须显式记账。

⚡AI 结对:建性能回归 CIpair with ai

review 重点:--compare 的比较逻辑里,方向别搞反(IOPS 是越高越好,P99 是越低越好, AI 在这种地方翻过车);CI 负载时长和阈值的权衡让它解释一遍 —— 30 秒短负载天然波动大,为什么 5% 是合理阈值,答不上来就说明它在背模板。

为 forge 建两层性能回归防线:

1. criterion 微基准:在 forge-store 和 forge-fs 加 benches 目录,覆盖 EC 编码(4+2, 4MB 条带)、crc32c(4KB 与 1MB)、WAL 单条追加、extent 分配器 alloc/free 混合负载;每个基准附一行注释说明它守护的是哪次优化;
2. forge-bench 宏观回归:给 forge-bench 加 --compare 子命令,输入两个结果 JSON,输出各指标变化百分比的 markdown 表格,任一关键指标(IOPS、吞吐、P99)退步超过阈值(默认 5%,可配)时进程退出码非 0;
3. GitHub Actions workflow:PR 触发,起单节点 forge 跑缩短版三种负载(每种 30s + 10s 预热),用 --compare 和主干基线比较,失败时把对比表格贴成 PR 评论;基线 JSON 在合并到主干后由 workflow 自动更新;
4. 报告脚本:scripts/perf-report.sh 一键跑全量基线(每种负载 5 遍取中位数)并生成含环境信息(CPU 型号、内核版本、盘型号、governor)的 JSON,供人工存档。

验收:本地跑 cargo bench 全绿;人为在 EC 编码里加一句 10ms sleep,criterion 与 --compare 两层都必须报出显著回退。

小结

调优纪律:基线 + 假设 + 测量 + 结论,四缺一都是玄学;基线用 forge-bench 钉死口径, 预热、多遍、环境三样记进报告
先测量后动手:火焰图管 CPU 热点,span 瀑布管 P99 长尾,两张图不可互替
存储系统四大惯犯:拷贝、分配、锁、系统调用;forge 的三刀 —— 自适应 group commit(+27%)、Bytes 零拷贝(+24%)、拆分配锁(+44%),全部达标且有据可查
性能回归 CI 两层防线:criterion 守函数,forge-bench 守整机;退步 5% 标红, 回退可以接受但必须显式记账
性能这一课收官,forge 1.0 的所有零件都齐了 —— 下一节全量验收,然后复盘这一路

下一课：收官：复盘与下一步 →