简介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.soWindows 下是 vdbench32.dll 和 vdbench64.dllSolaris 下对应 solx86-32.so、solx86-64.so、sparc32.so、sparc64.soAIX 和 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 各有侧重文件我通常怎么用example1最基础的随机 I/O入门先跑它example2多 workload 组合理解权重分配example3不同参数混合场景example4涉及多主机的分布式配置需要额外准备 slaves 文件example5延迟分布与直方图输出example6文件系统测试走 FSD 模式example7复杂工作负载接近混合应用不同版本 example 的具体内容会有差异以包内 readme 为准。我习惯先把 example1 和 example7 各跑一遍前者确认工具链没问题后者确认场景覆盖够不够。另外包里那份 errorlog.html 是运行期的错误页模板跑完测试后它会落在输出目录里里面有错误类型、发生时间、涉及哪台 slave排查时从它入手比瞎猜快得多。2.3 先改 config.shJava 环境与内存边界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 内存不够就会频繁 GCCPU 占用升高间接影响 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定运行时长、速率上限和指标上报间隔。一个最小可跑配置长这样sddefault,size2g,threads4 sdsd1,lun/dev/data01,formatyes wdwd1,sdsd1,xfersize4k,seekp100,rdpct80 rdrd1,wdwd1,ioratemax,elapsed300,interval5上面这段里sd 指向 /dev/data01先做格式化占 2GB 空间4 个并发线程wd 定义 4KB 块大小、100% 随机寻址、80% 读 20% 写rd 要求以最大速率跑 300 秒每 5 秒出一份指标。这里面的关键参数值得逐个过一遍参数作用常见取值xfersize单次 I/O 大小4k / 8k / 64k / 1mseekp随机寻址比例100全随机0全顺序rdpct读比例100纯读0纯写iorate速率控制固定 IOPS 或 maxelapsed运行秒数300 / 3600interval报告间隔秒数1 / 5 / 15数据生成器在 format 阶段会按固定算法生成确定性数据填满目标区保证测试结果不受磁盘上残留数据影响同时各 slave 节点之间的数据可校验。这一步是 vdbench 和很多简单打点工具最大的差别后面避坑章节我会专门讲 formatno 的后果。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: IOPS12453 MB/s48.6 resp7.8msIOPS、吞吐量 MB/s、平均响应时间 resp 是最先要看的三个数。改 example1 有个原则每次只动一个变量。想把纯读改成纯写就把rdpct100改成rdpct0想从随机改成顺序把seekp100改成seekp0。一次只改一个结果才能归因不然两个变量一起动出了异常你根本不知道是谁导致的。3.3 混合读写与 Fsync数据库场景的模拟方式生产环境很少有纯读或纯写数据库场景一般是小块随机读加重写日志的顺序写。vdbench 用多 wd 组合模拟这种形态wdwd1,sdsd1,xfersize8k,seekp100,rdpct90 wdwd2,sdsd1,xfersize32k,seekp0,rdpct0 rdrd1,wdwd1,ioratemax,elapsed120,interval5 rdrd2,wdwd1wd2,ioratemax,elapsed300,interval5wd1 模拟数据文件的随机读8KB 块90% 读wd2 模拟日志的顺序写32KB 块纯写。rd2 把两个 wd 用加号组合在一起并发跑压出来的就是接近数据库混合负载的曲线。如果关心掉电或 crash 场景下的同步写性能可以在 rd 层加fsyncyes这会强制每次写入后落盘吞吐量会明显下降这是正常现象不是工具出了问题。多 rd 并行也是 vdbench 并行测试能力的体现多个作业同时调度专门用来评估多任务环境下存储的表现。4. 多平台跑通Windows、Linux、AIX 的启动差异与参数边界vdbench 的跨平台能力是它能在存储圈活这么久的原因之一。但这套跨平台是有代价的每个平台要选对动态库、配对 Java 环境踩的坑还不一样。4.1 Windowsvdbench.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 位 dll64 位就配 64 位 dll。怎么查 JVM 位数命令行跑一下java -version输出里带 64-Bit 字样的就是 64 位。Windows 跑 vdbench 还有一个隐藏问题有些杀毒软件或系统自带的受控文件夹访问会拦截测试程序写盘导致 setup 阶段报权限错误。真遇到这种情况先把测试目录加白名单别一上来就怀疑配置文件写错了。4.2 Linuxconfig.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 结果虚高formatno 时读到的全是零现象第一次跑吞吐量特别高IOPS 漂亮得吓人但把同样参数拿到生产环境一比数字对不上。原因目标盘没有执行 format 或对全新文件直接开跑读到的全是零填充数据很多存储设备对全零数据有压缩或去重优化测出来的根本不是真实性能。解决在 sd 定义里加formatyes让 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 中断后残留文件与重复测试的脏数据现象测试中途 CtrlC 杀掉第二次跑同样配置时报错或者结果出现莫名其妙的低谷。原因中断时 vdbench 来不及清理临时文件半写的 offset 文件和数据文件残留下一次启动直接复用了脏状态。解决重新跑之前清理测试用到的文件和数据区。文件测试直接删掉目标文件重建裸设备测试重新执行 formatyes。我自己的习惯是每轮正式测试前强制 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 才是真凶。这套流程帮我挡掉了好几次交付验收的翻车希望帮到你。本文还有配套的精品资源点击获取