从零开始写分布式存储系统（6）性能测试三板斧

1.程咬金三板斧：要解决一个什么问题

用户故事： 作为性能测试工程师， 我想要快速定位并解决存储系统带宽不达标的紧急问题， 以便于系统能够满足预定的性能基准，保障项目交付进度

一天测试同事急匆匆提了一个Bug， 我在性能测试存储系统时发现带宽过低、性能不够，这是个紧急问题需要马上解决。

我想到性能问题，但Linux内核跟踪还没学会， 分布式系统的核心代码也不清楚，哪怕客户端测试场景也不清楚， 这让我非常着急上火，看日志，看命令，最后还是没有解决问题 。

领导 拿起刚泡好的茶 喝了一口 测试说 带宽不达标

衡量低标准是什么？

你怎么判断是操作系统本身问题

还是我们后端分布式系统问题

还是客户端压测问题，

客户端采用创建100个vmare 虚拟机来模拟写大文件 是单线程写吗？

要有大局观，基本边界分清楚？

这个定不清楚 ，后面无法解决问题

2. 程咬金三板斧：后端存储如何自证清白

2.1 利用操作系统自身提供工具

参考：极客时间《Linux性能优化实战》

网络免费版本：

https://freegeektime.com/posts/100020901/

在Linux性能优化中，当遇到带宽跑不满、服务响应慢的问题时，需要一个清晰的排查路径

文件IO

sar 是历史性能分析工具

/var/log/sa/  # 默认数据目录├── sa01      # 1号的历史二进制数据├── sa02      # 2号的├── sar01     # 1号的可读文本格式└── sar02

案例1：CPU 负载高，但使用率不高

现象：上午10点系统响应变慢，监控显示CPU使用率60%但负载平均达到15（4核CPU）

# 1. 查看问题时间段的CPU统计sar -u -f /var/log/sa/sa$(date +%d) -s 09:30:00 -e 10:30:00# 输出示例：# 10:00:01 AM     CPU     %user     %nice   %system   %iowait    %steal     %idle# 10:00:01 AM     all     15.12      0.00      8.34     60.01      0.00     16.53# 10:10:01 AM     all     18.09      0.00      9.12     65.21      0.00      7.58# 10:20:01 AM     all     20.45      0.00     10.11     70.12      0.00     -1.68

分析：

%iowait高达 60-70%，说明CPU在等待磁盘I/O

空闲CPU几乎为0，但用户态CPU使用并不高

结论：磁盘瓶颈导致进程等待，CPU空闲但负载高

深入调查磁盘：

# 2. 查看同时间段磁盘I/Osar -d -p -f /var/log/sa/sa$(date +%d) -s 09:30:00 -e 10:30:00# 输出示例：# 10:00:01 AM  DEV    tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await  svctm  %util# 10:00:01 AM  sda  1200.45   8000.12  15000.34     20.12     45.67    150.23   8.12   97.45# 10:00:01 AM  sdb    12.34     100.23    200.45     25.34      0.12      2.34   1.23    1.23

发现：

sda 的 %util97.45%，接近100%说明磁盘饱和

await150ms，I/O等待时间很长

avgqu-sz45.67，队列长度很长

解决方案：

# 定位是哪个进程导致高I/O# 但sar不记录进程级I/O，需要结合其他数据# 查看当时的系统日志grep "10:0[0-9]" /var/log/messages# 发现应用日志大量报错：数据库连接超时# 进一步检查数据库

iostat输出详解： 磁盘的实时性能和延迟概览

命令iostat -d 1 -x每秒刷新显示

Device:   rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s  avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda        0.00     1.23   45.67   89.01     5.12    12.34    128.12     2.34   10.12    8.34   11.23   7.12  95.67

rMB/s, wMB/s：最重要的读写流量指标

r/s, w/s：每秒读写操作次数（IOPS）

rrqm/s, wrqm/s：每秒合并的读写请求数

%util：设备使用率百分比

await：平均I/O等待时间（毫秒)

2.2 如何监控分布式存储系统 全链路IO追踪

perf

perf 是 Linux 系统性能分析工具集，全称是 Performance Event Counters。它基于 Linux 内核的 perf_events 子系统，能够提供硬件和软件层面的性能分析能力。

perf 的主要功能包括：

CPU 性能分析

函数调用追踪

硬件事件统计

软件事件监控

系统调用跟踪

系统自带【整个最重要，出问题了你现场敲命令统计吗？】

TIiDB Dashboard 监控 https://docs.pingcap.com/zh/tidb/stable/dashboard-monitoring/

https://zhuanlan.zhihu.com/p/531169548

ceph的工具很多，包括集群管理与运维，还有性能分析等等ceph osd perf

这个最重要 但是结合各自系统说明

3. 程咬金三板斧：客户端 如何自证清白

3.1 分布式数据库

通用型压测工具：Sysbench

Sysbench 是一款开源的、模块化的、跨平台的多线程性能测试工具，支持CPU、内存、磁盘I/O、线程以及数据库的性能测试。

它被广泛用于对MySQL、PostgreSQL等数据库进行基准测试，同样也适用于TiDB和OceanBase

TPC-C & TPC-H

TPC-C：专门针对联机交易处理系统（OLTP）的测试规范，模拟复杂的在线事务处理（如订单创建、支付、库存查询等），在大压力下测试数据库的事务处理能力，结果以tpmC（每分钟交易量）衡量

TPC-H：商业智能计算测试，用于模拟决策支持类应用（OLAP），包含22条复杂的分析查询，测试数据库在数据分析场景下的性能

Databench-C是混沌测试工具，用于模拟故障（如节点、网络、资源故障），测试分布式数据库在高可用和容错方面的韧性。

3.2 分布式存储 主流压测工具优缺点

dd命令

创建10GB的测试文件 dd if=/dev/zero of=testfile bs=1M count=10240

直接I/O支持 可通过oflag=direct绕过缓存测试真实磁盘性能

仅支持单线程顺序I/O，无法模拟随机访问、并发访问等真实场景

dd的同步阻塞模式（iodepth=1）无法体现多队列NVMe的优势。

FIO

FIO（Flexible I/O Tester）是一个功能强大的I/O性能测试与压力测试框架，其核心设计哲学在于模块化与可扩展性，特别是通过其独特的I/O引擎（ioengine）架构来支持多样化的I/O操作方式

优点：

高度灵活：支持13种不同类型的I/O引擎（包括sync、mmap、libaio、posixaio、splice等），可模拟多种真实负载场景。

并发模拟能力强：支持多线程、多进程并发测试，能够充分体现现代存储设备（如NVMe的多队列）的性能优势。

测试场景全面：可测试顺序/随机读写、混合读写比例、不同I/O大小、队列深度等关键参数，适用于块设备和文件系统测试。

在滴滴的Ceph分布式存储系统优化实践中，Fio被用于验证锁优化效果,-异步读优化后，随机写平均延迟下降了53%

Fio测试能够帮助识别分布式存储系统中的性能瓶颈所在：

网络瓶颈：通过对比本地存储和远程存储的测试结果，判断网络是否成为性能限制因素

存储节点瓶颈：通过在不同节点上运行Fio测试，识别性能较弱的节点

软件栈瓶颈：对比不同I/O引擎（如libaio、io_uring、SPDK）的性能表现，选择最适合的软件架构

3. vdbench

优点：

集群测试能力强：专为测试整个存储集群性能设计，支持多主机、多客户端并发测试，适合分布式存储系统评估。

参数配置丰富：提供详细的存储定义（SD）、工作负载定义（WD）、运行定义（RD）等参数，可精细控制测试过程。

文件系统与块设备兼顾：支持文件系统测试（FSD/FWD）和裸设备测试，配置灵活。

结论：

对于分布式存储系统压测，Vdbench是更专业、更便捷的选择。

它提供了开箱即用的多节点管理、任务分发和统一报告，能更好地模拟真实生产环境中的多客户端负载。

真多裸盘 极限性能FIO

问：对于在100个客户端建立VMware虚拟机进行IO压力测 合适吗？ 不合适

Vdbench从设计之初就支持多主机、多客户端的联机测试 可以轻松组织跨数十甚至上百个节点的并发压力测试

相比之下，Fio虽然也支持多客户端测试（通过--server和--client模式），但需要手动在每台客户端启动服务端，并

祝：

下定决心：

努力不挣钱没关系，

关键不要赔上百万，千万，

熬夜看手机就是 对眼睛，无法恢复的伤害。

一个亿也无法挽回。

手碰一下手机，耳朵听手机声音，看手机屏幕，还是看消息内容

陷入这样 虚拟世界，

无论现实遇到什么问题，哪怕活不到好工作，好项目，好机会

哪怕什么都不懂，努力 0收入 赔上百万，千万都不重要。

都不超过1个亿，最后还是赚了。

2026 重启手机，重启人生

对你操作系统赋予新意义开启

不要独自一个人看手机，

我们常常陷入这样的场景： 独自一人时，在餐厅、地铁、卧室、沙发或书桌前， 当你躺在那里，趴在哪里，做在哪里时候，身体固定狭小空间，无法互动 ，不自觉地掏出手机。 身体被困在狭小的物理空间里，无法动弹， 只能目光便只能被那方寸屏幕牢牢吸引， 你行为被 多巴胺诱惑，简单舒服即使反馈奖励 ，被平台设计各种陷阱控制

除非拥有极强的意志力，根本不选择痛苦迟到的奖励

与其对抗本能，甚至平台 不如改变环境。 请选择去户外，去操场，视眼开阔 看手机。 请主动为你的手机使用选择更健康的场景

核心行动准则1：为特定场景设立无手机时间

进入公司开始工作时

下班回到家中时

在餐厅用餐或社交时

乘坐地铁通勤时

行动建议：

在上述场景开始时，立刻将手机放入书包或固定在某个位置（如抽屉）。

给自己设定一个专注时限，例如至少接下来的3小时内不主动查看。

这能有效打破“无聊就刷手机”的循环，把注意力还给当下的人和事。

核心行动准则2：换个开阔的地方看手机

早晨起床后

下班之后

周末时光 行动建议：

可以选择去图书馆、咖啡馆、商场中庭或景点休息区，公司园区，马路边

在这些具有公共生活感的场所使用手机，

周围的环境流动能天然地分散你对屏幕的过度专注，避免陷入无休止的刷屏。

一句话描述：

普通人最简单方式，重启自己操作系统

固定21点入睡：1 R90睡眠方案之所以能这样的世界顶尖运动员所青睐，每天晚上的睡眠规律你可以

固定6点起床：2 成不了作家 你可以打开笔记本写一行文字，3 做不出产品产品你打开软件写一行代码，4 无法演讲信服的话，你自己说一句话。5 成不运动健身达人 你走到运动走一步

今日记录

本周：

中午 做电梯 和早晨，中午 晚上看手机时间太长。

看微信时间太长

解决方案

•离开工位，走进电梯 手机马上禅道 30分钟，不强制锁屏30分钟 吃饭时候不带手机。手机不放到身边 [没有人给你打电话 都是错觉]

•微信使用完毕 退出微信登录

•微信限制使用时长，不解锁，不解锁，自己每天解锁了

做了什么改进

•用饭卡，刷脸 代替 手机，手机 中午吃饭，晚上吃饭 放到公司 拿出去。

•强制锁屏，自动锁屏

•微信使用完毕：开启青少年模式，限制使用时间。 退出登录 三个方式。不要嫌弃麻烦

•使用完毕在回复

最大问题，手机开启青少年模式 没法发表视频号？

你的问题早就答案，从电脑端发表 你的问题早就答案，从电脑端发表 你的问题早就答案，从电脑端发表 你的问题早就答案，从电脑端发表