观测与压测工具箱

把前面几节串成一套手法

到这里，L0 的知识点已经齐了。这一节不引入新概念，而是把工具组织成可复用的动作：遇到什么问题，按什么顺序，敲哪些命令。

工具分两类，代价完全不同：

顺序永远是：先用零开销的工具收敛范围，再用追踪工具挖根因。反过来做，你会在生产机器上跑一个高开销的 trace，然后被业务方投诉。

压测：elbencho 的四件套

压测不是"跑个分"，是回答一个具体问题。先想清楚问题，再选参数。

本课统一用 elbencho —— 它由 BeeGFS 创始人开发，一个工具覆盖了 fio、mdtest、ior 的功能，块设备、文件系统、S3 都能压，而且原生支持多客户端协同。学一套参数就够用。

# 1. 顺序写 —— 回答"这块盘的写带宽上限是多少"
elbencho -w --direct -b 1M -t 4 --iodepth 32 \
         -s 100g --timelimit 60 --lat /dev/nvme0n1

# 2. 顺序读 —— 回答"读带宽上限"
elbencho -r --direct -b 1M -t 4 --iodepth 32 -s 100g --timelimit 60 /dev/nvme0n1

# 3. 随机写 —— 回答"数据库类负载能跑多少 IOPS"
elbencho -w --direct -b 4k -t 4 --iodepth 64 --rand --randamount 50g \
         -s 100g --timelimit 60 --lat --latpercent /dev/nvme0n1

# 4. 随机读 —— 回答"元数据类负载能跑多少 IOPS"
elbencho -r --direct -b 4k -t 4 --iodepth 64 --rand --randamount 50g \
         -s 100g --timelimit 60 --lat --latpercent /dev/nvme0n1

必须理解的几个参数：

压测：多客户端压共享文件系统

单机压出来的数字只是上限参考。共享文件系统（CephFS、GPFS）需要多客户端并发才能压出真实能力——同一个 elbencho，加上 service 模式即可：

# 每台客户端上先起一个 service（后台常驻）
elbencho --service

# 协调节点统一发起：4 台客户端一起压同一个文件系统
elbencho --hosts client1,client2,client3,client4 \
         -w -b 4M -t 16 --direct -s 100g /mnt/cephfs/bench/file

# 多文件（元数据）性能：这才是共享文件系统真正的考验
elbencho -w -d -n 100 -N 10000 -s 4k -t 16 /mnt/cephfs/bench

# 块设备：一次压多块盘，验证整机能力
elbencho -w -b 4M -t 48 --direct -s 100g /dev/nvme{0..11}n1

lspci -vvv | grep 'Non-Volatile'          # 拿到 PCIe 地址，如 5a:00.0
lspci -s 5a:00.0 -vvv | grep 'Speed'
#   LnkCap: Speed 16GT/s, Width x4
#   LnkSta: Speed 16GT/s (ok), Width x1 (downgraded)   ← 掉到 x1 了

结果怎么读：first done 与 last done

elbencho 的结果表有两列数字，很多人只看右边一列就走了，其实这两列之间的差距本身就是结论：

OPERATION RESULT TYPE        FIRST DONE  LAST DONE
========= ================== ==========  =========
WRITE     Elapsed ms       :      41230      68940
          IOPS             :      12470       7460
          Throughput MiB/s :       4870       2910
          Total MiB        :     200704     200704

• first done = 第一个工作线程（多客户端时是第一个 host）干完自己那份活时的统计。此刻所有线程都还在跑，机器处于满载、竞争均衡的状态，所以这一列代表并发拉满时的峰值能力。
• last done = 最后一个线程干完时的统计，也就是整个作业的真实完成时间。这一列包含了后半段"快的已经收工、慢的还在磨"的拖尾，所以它是你真正能对外承诺的聚合数字。

上面这组数据里 last done 的带宽只有 first done 的六成，说明最快和最慢的线程差了 27 秒——这不是一次可信的压测，是一次暴露了不均衡的压测。

一句话记法：想知道"这堆盘、这张网到底能跑多快"，看 first done；想知道"这批活干完要多久"，看 last done。

差距过大的常见原因

动态追踪：bpftrace 一行流

当静态工具告诉你"盘的平均延迟是 15ms"，但你需要知道是谁在发这些慢 I/O，就该上 bpftrace 了。

# 1. I/O 延迟分布直方图 —— 看清长尾
biolatency-bpfcc 10 1

# 2. 逐条打印 I/O，含进程名、扇区、延迟
biosnoop-bpfcc | head -40

# 3. 按进程统计 I/O 大小
bpftrace -e 'tracepoint:block:block_rq_issue { @[comm] = hist(args->bytes); }'

# 4. 抓超过 100ms 的慢 I/O 及其调用栈
bpftrace -e 'kprobe:blk_account_io_done /nsecs/ { ... }'

biolatency 的输出最能说明问题：

     usecs               : count     distribution
         0 -> 127        : 84213    |████████████████████████████████████████|
       128 -> 255        : 12043    |█████                                   |
       256 -> 511        : 3211     |█                                       |
    ...
     16384 -> 32767      : 89       |                                        |   ← 长尾在这

平均延迟可能只有 0.2ms，但这 89 个 16ms 以上的请求，就是业务侧感知到的卡顿来源。

压测报告怎么写才有说服力

跑完数字只是原料。一份能用于决策的报告要包含：

## 测试环境
- 硬件：8 × Dell R750，每节点 12 × 7.68TB NVMe，2 × 25GbE
- 软件：Ceph 20.2.1，3 副本，pg_num=256
- 客户端：4 台，与存储节点独立

## 测试方法
- 工具：elbencho 3.1-7（4 台客户端 service 模式）
- 参数：见附录完整命令行
- 数据量：每线程 100 GiB（远超节点内存，避免只测到缓存与启动开销）
- 每组跑 300 秒，取稳态区间；每组重复 3 次取中位数

## 结果
| 场景 | 块大小 | 队列深度 | IOPS | 带宽(last done) | 平均延迟 | P99 延迟 | first/last 差距 |
| ... |

## 结论与瓶颈判断
- 顺序写在 11.2 GB/s 见顶，与 cluster 网理论上限吻合 → 瓶颈在网络
- 4K 随机写 IOPS 未达单盘能力之和的 50% → 需进一步排查

## 未覆盖的场景
- 未测试恢复期间的性能衰减
- 未测试多租户混合负载

这节课的落点

• 先用零开销的静态工具收敛范围，再用 bpftrace 类工具挖根因
• elbencho 四件套：顺序读写测带宽、随机读写测 IOPS；--direct 必加，--timelimit 时长要够
• 同一个 elbencho 加 --service / --hosts 就能多客户端压共享文件系统，尤其是多文件元数据场景
• 结果表看两列：first done 是满载峰值，last done 是这次运行的聚合完成情况；差距超过 20% 先查不均衡（数据量太小、慢盘、切分不均、分布不均、后台任务），别急着记数字
• 判断硬件性能上限、做验收对比理论值只用 first done；拿被拖尾稀释过的 last done 去比理论值，会误判成"硬件不达标"
• 报告不能直接抄 last done：两列都写、注明数据量与时长、重复 3 次取中位数，结论给区间并解释差距来源
• 裸盘压测顺便用 lspci 查 PCIe 是否 downgraded，这类硬件问题要在上线前发现
• 报告必须写清方法、环境和未覆盖的场景

L0 到此结束。你已经具备了在任何一台 Linux 机器上定位性能问题的基本能力——接下来把这套能力用到分布式存储上。