Vdbench存储压测实战：配置、跨平台与避坑指南

简介：Vdbench性能测试工具包，面向存储工程师、运维人员与性能测试初学者，可在Linux、Windows、Solaris等平台运行，用于评估硬盘、SSD及存储阵列的I/O能力，通过随机读写、顺序读写、混合读写等负载模型定位存储瓶颈，为性能优化提供依据。压缩包共61个文件、2.91MB，内含vdbench.jar核心程序、不同平台所需的so/dll动态库、sh/bat启动脚本、txt说明文档、pdf用户手册，以及example1-7等典型配置模板和seq_read、random_rw、seq_write等场景示例，覆盖从基础参数设置到分布式测试的完整路径。用户可按需调整I/O大小、并发线程数、运行时长等参数。目前已有763人学习下载。借助包内数据生成器，可模拟数据库写入、视频流顺序读取等实际应用负载；配合并行与分布式测试能力，能直观比较延迟、吞吐量等指标，快速评估存储系统极限性能，是存储选型、系统调优和故障排查中的实用工具。

1. Vdbench 到底测什么：一台存储设备的极限与水位

线上数据库慢查询频发，存储工程师盯着监控面板一脸懵——磁盘利用率只有 30%，应用延迟却下不来。这种时候，我一般不会急着调参，而是先掏 vdbench 把存储的真实水位摸一遍。vdbench 是存储压测圈里的老牌工具，一个 jar 包加一堆平台动态库就能跑，能模拟随机读写、顺序读写、混合读写甚至 fsync 场景，输出 IOPS、吞吐量和延迟分布。这份资源包里带了 vdbench.jar、各平台动态库、官方 PDF 和 example1 到 example7 全套示例，最快半小时就能对一块盘、一个阵列甚至一套分布式存储跑出可对比的基线。适合做存储选型、系统交付验收和故障排查的工程师，新手照着 example1 改参数也能跑通。

2. 运行机制先看透：Jar 包、Native 动态库与一堆 Platform 文件的分工

第一次解压这个包的人，很容易被顶层的一堆文件看花眼：jar、so、dll、config.sh、vdbench.bat、七八个 example。实际上它们分工非常明确，搞懂之后跑测试，报错定位会快很多，不至于一上来就对着 errorlog.html 发懵。

2.1 vdbench.jar、动态库与 JNI 分工

vdbench.jar 是整个工具的大脑，负责解析参数、调度作业、归并结果。它本身是纯 Java 的，跨平台能力靠 JVM 保证。但真正写盘读盘时，Java 直接发系统调用不方便，于是通过 JNI 调用本机动态库：Linux 下是 linux32.so 和 linux64.so，Windows 下是 vdbench32.dll 和 vdbench64.dll，Solaris 下对应 solx86-32.so、solx86-64.so、sparc32.so、sparc64.so，AIX 和 HP 平台也各有对应的库。包里按平台分好了目录，用哪个取决于你的操作系统和 CPU 架构。

这里最容易翻车的是位数匹配。64 位系统配 64 位 JVM，就必须用 64 位动态库；如果 Java 是 32 位而库是 64 位，启动阶段就会报Unable to open shared library之类的错误。这个错我在 Windows 上见过最多，新手总以为是包坏了，其实只是 JDK 位数和 DLL 对不上。另外，classes 目录下那堆 VdbComp、Vdb、Utils 类，负责的是工作负载建模和数据校验，正常使用时不用管，但它们的存在决定了 vdbench 的扩展性——你可以通过继承 Vdb 类实现自定义 I/O 模式，不过那是高阶玩法了。

2.2 examples 与文档的正确读法

包里有两种文档：根目录的 readme.txt 和 vdbench.pdf。根目录 readme 是快速开始，examples 目录下还有一份 readme.txt，后者更贴近示例玩法。我不建议一上来通读 PDF，那是字典不是教程，正确路径是先跑通一个 example，再回来翻参数定义。examples 目录里 example1 到 example7 各有侧重：

不同版本 example 的具体内容会有差异，以包内 readme 为准。我习惯先把 example1 和 example7 各跑一遍，前者确认工具链没问题，后者确认场景覆盖够不够。另外包里那份 errorlog.html 是运行期的错误页模板，跑完测试后它会落在输出目录里，里面有错误类型、发生时间、涉及哪台 slave，排查时从它入手比瞎猜快得多。

2.3 先改 config.sh：Java 环境与内存边界

Linux 和 Solaris 下启动 vdbench 之前，先过一遍 config.sh。这个脚本干两件事：把 Java 路径加进 PATH，再给 JVM 设置堆内存参数。我一般会改成这样：

# 解压后先改这里，路径换成你机器上实际的 JDK export JAVA_HOME=/usr/local/jdk1.8.0_202 export PATH="$JAVA_HOME/bin:$PATH" # 控制 JVM 堆，测试规模越大越要留足 export JVM_OPTIONS="-Xms1g -Xmx4g" # 跑第一个示例 ./vdbench -f examples/example1 -o /tmp/vdb_out1

堆内存这个参数经常被忽略。interval 设得很密、历史数据保留很多、分布式 slave 数量多时，JVM 内存不够就会频繁 GC，CPU 占用升高，间接影响 I/O 测试结果。我一般至少给 4GB，跑大规模分布式测试时给到 8GB。Windows 上对应的入口是 vdbench.bat，双击或命令行调用都行，但系统环境变量里必须先配好 JAVA_HOME，否则批处理会直接退出去。

3. 配置文件实战：sd/wd/rd 三层模型与三个官方示例的改法

vdbench 的配置语法说穿了就三个块：sd 定义被测存储，wd 定义 I/O 特征，rd 定义怎么跑。几乎所有测试场景都是这三层的排列组合。很多第一次用的人喜欢直接改 example 里的参数，跑通了就不管了，结果过两天换台机器换个盘就不知道怎么调，本质还是没吃透这三层。

3.1 sd/wd/rd 三层结构与数据流

sd 是 Storage Definition，指定目标磁盘、LUN 或者测试文件，同时定义并发线程数；wd 是 Workload Definition，在这块存储上跑什么 I/O，块多大、随机还是顺序、读多还是写多；rd 是 Run Definition，定运行时长、速率上限和指标上报间隔。一个最小可跑配置长这样：

sd=default,size=2g,threads=4 sd=sd1,lun=/dev/data01,format=yes wd=wd1,sd=sd1,xfersize=4k,seekp=100,rdpct=80 rd=rd1,wd=wd1,iorate=max,elapsed=300,interval=5

上面这段里，sd 指向 /dev/data01，先做格式化，占 2GB 空间，4 个并发线程；wd 定义 4KB 块大小、100% 随机寻址、80% 读 20% 写；rd 要求以最大速率跑 300 秒，每 5 秒出一份指标。这里面的关键参数值得逐个过一遍：

数据生成器在 format 阶段会按固定算法生成确定性数据填满目标区，保证测试结果不受磁盘上残留数据影响，同时各 slave 节点之间的数据可校验。这一步是 vdbench 和很多简单打点工具最大的差别，后面避坑章节我会专门讲 format=no 的后果。

3.2 从 example1 起步：第一个随机读测试怎么改

example1 是最短的入口，直接跑：

./vdbench -f examples/example1 -o /tmp/vdb_out1

跑起来后，终端会先打印启动信息、slave 数量和 Java 版本，然后进入格式化阶段，再开始打 I/O。一段典型的报告长这样：

06/10 12:00:00 Starting 1 slaves ... 06/10 12:05:00 sd1: IOPS=12453 MB/s=48.6 resp=7.8ms

IOPS、吞吐量 MB/s、平均响应时间 resp 是最先要看的三个数。改 example1 有个原则：每次只动一个变量。想把纯读改成纯写，就把rdpct=100改成rdpct=0；想从随机改成顺序，把seekp=100改成seekp=0。一次只改一个，结果才能归因，不然两个变量一起动，出了异常你根本不知道是谁导致的。

3.3 混合读写与 Fsync：数据库场景的模拟方式

生产环境很少有纯读或纯写，数据库场景一般是小块随机读加重写日志的顺序写。vdbench 用多 wd 组合模拟这种形态：

wd=wd1,sd=sd1,xfersize=8k,seekp=100,rdpct=90 wd=wd2,sd=sd1,xfersize=32k,seekp=0,rdpct=0 rd=rd1,wd=wd1,iorate=max,elapsed=120,interval=5 rd=rd2,wd=wd1+wd2,iorate=max,elapsed=300,interval=5

wd1 模拟数据文件的随机读，8KB 块，90% 读；wd2 模拟日志的顺序写，32KB 块，纯写。rd2 把两个 wd 用加号组合在一起并发跑，压出来的就是接近数据库混合负载的曲线。如果关心掉电或 crash 场景下的同步写性能，可以在 rd 层加fsync=yes，这会强制每次写入后落盘，吞吐量会明显下降，这是正常现象，不是工具出了问题。多 rd 并行也是 vdbench 并行测试能力的体现，多个作业同时调度，专门用来评估多任务环境下存储的表现。

4. 多平台跑通：Windows、Linux、AIX 的启动差异与参数边界

vdbench 的跨平台能力是它能在存储圈活这么久的原因之一。但这套跨平台是有代价的：每个平台要选对动态库、配对 Java 环境，踩的坑还不一样。

4.1 Windows：vdbench.bat 启动与 DLL 位数匹配

Windows 下的启动入口是 vdbench.bat，命令行进到 vdbench 目录直接调：

vdbench.bat -f examples\example1 -o output

路径分隔符一定要用反斜杠，这是 Windows 批处理和 Linux shell 最直观的差别。我见过有人把 example1 的路径写成正斜杠，结果批处理把参数拆得七零八落。Windows 上最容易出的问题是 vdbench32.dll 和 vdbench64.dll 的选择：JVM 是 32 位就配 32 位 dll，64 位就配 64 位 dll。怎么查 JVM 位数？命令行跑一下java -version，输出里带 64-Bit 字样的就是 64 位。

Windows 跑 vdbench 还有一个隐藏问题：有些杀毒软件或系统自带的受控文件夹访问会拦截测试程序写盘，导致 setup 阶段报权限错误。真遇到这种情况，先把测试目录加白名单，别一上来就怀疑配置文件写错了。

4.2 Linux：config.sh 环境与 32/64 位动态库

Linux 下的部署路径我一般是这样走：

unzip vdbench.zip -d /opt/vdbench chmod +x /opt/vdbench/config.sh /opt/vdbench/vdbench cd /opt/vdbench ./config.sh ./vdbench -f examples/example1 -o /tmp/vdb_out

启动阶段最常见的报错是linux64.so: cannot open shared object file。先别急着怀疑包损坏，按顺序查三件事：第一，java -version确认 Java 位数；第二，file vdbench.jar确认 jar 是 64 位编译；第三，确认 ldconfig 能找得到 libc 的 64 位版本。另外，如果目标是裸设备或分区，记得确认当前用户对它有写权限，Vdbench 在 format 阶段是直接写底层块设备的，没有 root 权限基本跑不了裸盘测试。

4.3 多盘并行与服务器端分布式雏形

多盘并行不需要额外配置，在 sd 里多定义几个块就行，每个 sd 指向不同 lun，线程数按盘的能力分配。真正要上规模的是分布式测试，先在节点上准备一个 slaves 文件：

node1 node2 node3

然后带上 slave 参数启动：

./vdbench -f /opt/vdbench/examples/example4 -o /tmp/vdb_dist slave=/opt/vdbench/slaves

每个 slave 节点都要放同一套 vdbench 目录，Java 版本必须一致，防火墙要放行 vdbench 使用的通信端口，否则会报 slave 连接失败。这个模式是模拟大规模并发 I/O 的基础，企业级存储阵列做交付验收时几乎必用。Vdbench 会把 jar 包和配置自动分发到各 slave，你只需要保证目录可读和网络通畅。

5. 避坑记录：格式化、缓存、Slave 连接与结果判读的五条血泪经验

这一章是全文最值钱的部分。下面五条都是我在实际压测中踩过的坑，每一条都按现象、原因、解决的顺序写清楚，你遇到时直接对照。

5.1 结果虚高：format=no 时读到的全是零

现象：第一次跑吞吐量特别高，IOPS 漂亮得吓人，但把同样参数拿到生产环境一比，数字对不上。原因：目标盘没有执行 format 或对全新文件直接开跑，读到的全是零填充数据，很多存储设备对全零数据有压缩或去重优化，测出来的根本不是真实性能。解决：在 sd 定义里加format=yes，让 vdbench 先用确定性数据填满整个目标区域再开始测试。代价是 format 本身要花时间，大容量盘可能要跑几十分钟，但这一步省不得。

5.2 缓存把结果变成玄学

现象：同一台机器连续跑两次同样的配置，第二次明显快，第三次又变慢，结果完全不可复现。原因：操作系统页缓存把热数据留在内存里了，第二次跑大量命中缓存，测的是内存不是存储。解决：裸设备测试影响相对小，文件系统测试（FSD 模式）影响巨大。我一般会在大块随机场景下用大文件减少缓存收益，或者干脆每轮测试前重启目标服务、让缓存失效。记住一个原则：vdbench 测的是存储，不是缓存，任何让数据留在内存里的操作都是在污染结果。

5.3 Slave 连接失败与分布式测试中断

现象：分布式测试跑到一半，终端报Connection refused或Slave timeout，所有结果作废。原因：三个常见来源——防火墙拦了通信端口、slave 节点 Java 版本不一致、slave 上 vdbench 目录权限不对。解决：先telnet或nc测端口连通性，再统一所有节点java -version，最后确认 slave 上 vdbench 目录对运行用户可读写。这套排查顺序我走了无数次，每次都有效。

5.4 中断后残留文件与重复测试的脏数据

现象：测试中途 Ctrl+C 杀掉，第二次跑同样配置时报错，或者结果出现莫名其妙的低谷。原因：中断时 vdbench 来不及清理临时文件，半写的 offset 文件和数据文件残留，下一次启动直接复用了脏状态。解决：重新跑之前，清理测试用到的文件和数据区。文件测试直接删掉目标文件重建，裸设备测试重新执行 format=yes。我自己的习惯是每轮正式测试前强制 format 一遍，就当买后悔药。

5.5 errorlog.html 里的错误怎么读

现象：测试跑完了，报告也生成了，但 output 目录里的 errorlog.html 全是条目，数字没法采信。原因：errorlog.html 记录的是运行期间的错误事件，常见的有 I/O error、Setup error、Oversized 和落盘超时。解决：打开 errorlog.html 按错误类型归类，I/O error 多半指向设备本身，Setup error 多半是配置问题。如果错误条目只占总 I/O 的千分之几，可以忽略；如果超过百分之一，这次测试结果就得废弃重跑。

6. 进阶：用系统监控与交叉工具让 Vdbench 的数字真正可信

跑出 IOPS 和延迟不等于测试结束，真正的验证是让 vdbench 的数字和系统监控互相印证。我现在的标准流程分三步。第一步是预跑：小规模、短时长、低并发先跑 60 秒，确认 errorlog 干净、slave 全在线、格式化和数据校验没报错，再上正式的长时长测试。正式测试至少跑 3600 秒，elapsed 太短连预热都不够。

第二步是监控对照。vdbench 跑的时候，另外开一个终端执行iostat -x 1，看盘符的 %util、await 和 svctm。如果 vdbench 报告 IOPS 很高但 iostat 显示 %util 只有 20%，要么打到了缓存，要么线程没真正并发，结果要打个问号。反过来 vdbench 延迟正常但 iostat 显示队列深度爆表，说明存储端排队严重，系统存在瓶颈。两边对不上时，优先相信 iostat 的底层数据。

第三步是交叉验证。时间允许的话，同一台设备用 fio 配相近参数跑一轮，libaio 引擎、同样的块大小和队列深度，两边 IOPS 和延迟做对比。vdbench 和 fio 的调度方式不同，数字不会完全一致，但量级应该落在同一区间。相差一个数量级，必然是某一侧的配置出了问题。

这里有一个我交过学费的教训：早年间做一次交付验收，只看了 vdbench 报告里的平均响应时间，觉得性能很稳，结果业务高峰一到，延迟直接打爆。从那以后，我每次正式压测都强制在 rd 层开启直方图输出，把响应时间按区间分布记录下来，同时把 interval 设成 1 秒拿明细数据，重点盯最大响应时间和 95 分位，而不是平均值。平均延迟 5ms 不代表应用不卡，最大延迟 500ms 才是真凶。这套流程帮我挡掉了好几次交付验收的翻车，希望帮到你。

本文还有配套的精品资源，点击获取