JuiceFS 如何用 fio 跑顺序读写基准测试并解读结果

JuiceFS 如何用 fio 跑顺序读写基准测试并解读结果

【免费下载链接】juicefsJuiceFS is a distributed POSIX file system built on top of Redis and S3.项目地址: https://gitcode.com/GitHub_Trending/ju/juicefs

已经挂载好的 JuiceFS 文件系统能跑多快的顺序读写、瓶颈出现在哪一层，可以用 fio 在挂载点上直接压测，再配合juicefs stats的实时指标来解读。官方 fio 基准测试文档用fio3.1 在 JuiceFS 上执行了单 job 与 16 并发两档顺序读/写测试（同时以 EFS、S3FS 作为对照），并给出了测试环境与挂载选项。这篇文章把这条路径整理为可直接执行的步骤：先准备好挂载点和测试目录，跑顺序读写测试，然后看输出与客户端指标，判断结果的含义。

准备条件

已 format 并挂载的文件系统

先按 Standalone Mode 的流程创建并挂载文件系统。以 SQLite 元数据 + S3 对象存储为例（命令中的密钥与桶地址是文档示例值，需替换为你自己的实际值）：

juicefs format --storage s3 \ --bucket https://myjfs.s3.us-west-1.amazonaws.com \ --access-key ABCDEFGHIJKLMNopqXYZ \ --secret-key ZYXwvutsrqpoNMLkJiHgfeDCBA \ sqlite3://myjfs.db myjfs juicefs mount sqlite3://myjfs.db /jfs

后文的 fio 命令默认挂载点为/jfs，如果你的挂载点不同（例如/mnt/jfs），把命令中的--directory和juicefs stats的路径替换掉即可。

测试前禁用 Trash

JuiceFS v1.0+ 默认开启 Trash：基准测试过程中创建又删除的临时文件会进入文件系统根目录下的.trash，在过期前持续占用文件系统与对象存储空间。为避免这个问题，测试前执行：

juicefs config META-URL --trash-days 0

META-URL是你 format 时使用的元数据地址（如sqlite3://myjfs.db）。测试完成后如需恢复回收站，再执行juicefs config META-URL --trash-days=7之类的命令改回保留天数，详见 Trash 文档。

fio 工具

文档中的测试使用fio3.1，安装方式按你的发行版常规包管理处理。

执行顺序读写测试

以下命令来自 fio.md。原始测试在 JuiceFS、EFS、S3FS 三个文件系统上跑同一组命令用于对比；如果只测 JuiceFS，保留--directory=/jfs的这几条即可。

单 job（numjobs: 1）

# 顺序读 fio --name=sequential-read --directory=/jfs --rw=read --refill_buffers --bs=4M --size=4G # 顺序写 fio --name=sequential-write --directory=/jfs --rw=write --refill_buffers --bs=4M --size=4G --end_fsync=1

参数含义（依据文档说明）：

• --rw=read/--rw=write：顺序读 / 顺序写；
• --bs=4M：每次 IO 的大小；
• --size=4G：每个线程 IO 的总大小，通常等于测试文件大小；
• 写命令比读命令多带--end_fsync=1；--refill_buffers和--end_fsync=1文档未展开解释，命令按原文保留。

16 并发 job（numjobs: 16）

# 顺序读 fio --name=big-file-multi-read --directory=/jfs --rw=read --refill_buffers --bs=4M --size=4G --numjobs=16 # 顺序写 fio --name=big-file-multi-write --directory=/jfs --rw=write --refill_buffers --bs=4M --size=4G --numjobs=16 --end_fsync=1

--numjobs是并发测试线程数，默认每个线程使用各自独立的测试文件。

文档的测试环境

文档给出的结果是在下列环境上跑出来的，可作为环境参照，不要把它当成固定预期：

• 一台 c5d.18xlarge EC2（72 CPU、144G RAM），Ubuntu 18.04 LTS（Kernel 5.4.0）；
• JuiceFS 元数据用本地 Redis（版本 4.0.9）；
• 挂载时使用了--max-uploads=150 --io-retries=20：

./juicefs format --storage=s3 --bucket=https://<BUCKET>.s3.<REGION>.amazonaws.com localhost benchmark ./juicefs mount --max-uploads=150 --io-retries=20 localhost /jfs

其中<BUCKET>、<REGION>需替换为你自己的 S3 桶名与区域，localhost指本地 Redis 地址。

可选：性能评估指南中的 libaio 变体

Performance Evaluation Guide 另外给出一组单机 fio 测试，用libaio与--direct=1，IO 粒度为 1 MiB、每线程 1 GiB、4 并发：

# 顺序写 fio --name=jfs-test --directory=/mnt/jfs --ioengine=libaio --rw=write --bs=1m --size=1g --numjobs=4 --direct=1 --group_reporting # 顺序读 fio --name=jfs-test --directory=/mnt/jfs --ioengine=libaio --rw=read --bs=1m --size=1g --numjobs=4 --direct=1 --group_reporting

文档对参数的说明：--ioengine指定发送 IO 的方式，通常用libaio；--direct在打开文件时加O_DIRECT标志位以禁用系统缓冲，使测试结果更稳定准确；--name是测试名（影响测试文件名），--directory是测试目录，--bs、--size、--numjobs含义同前。--group_reporting文档未解释，命令按原文保留。

该指南给出的结果（文档示例，不代表你环境应得到的数值）：

# Sequential WRITE: bw=703MiB/s (737MB/s), 703MiB/s-703MiB/s (737MB/s-737MB/s), io=4096MiB (4295MB), run=5825-5825msec READ: bw=817MiB/s (856MB/s), 817MiB/s-817MiB/s (856MB/s-856MB/s), io=4096MiB (4295MB), run=5015-5015msec

解读结果

先看 fio 输出本身：每个 job 给出bw（带宽）、io（总数据量）、run（耗时）三个字段，顺序读写带宽直接取bw。

文档中的对比图显示，在其测试环境下 JuiceFS 的顺序读写吞吐量明显高于 EFS 和 S3FS，Performance Benchmark 页面给出的结论是该次测试中 JuiceFS 提供约 10 倍于另外两者的吞吐量。这是特定环境（c5d.18xlarge + 本地 Redis + S3）下的结果，不能直接作为你环境的验收值。

更可靠的做法是在测试运行期间，另开一个终端执行：

juicefs stats /mnt/jfs --verbosity 1

（路径同样替换为你的挂载点。）juicefs stats以类似dstat的格式实时输出客户端指标，用于判断带宽瓶颈在哪一层：

各指标如何读（摘自 Real-Time Performance Monitoring）：

• fuse的read/write：FUSE 层读写带宽，可与 fio 输出的bw对照；ops/lat是每秒操作数与平均延迟（ms）。
• usage的buf：当前 buffer 大小。如果该值持续接近甚至超过配置的--buffer-size，应增大 buffer size 或降低应用负载。
• meta的ops/lat：元数据操作每秒数量与平均延迟；txn/lat是写事务速率。顺序大块 IO 测试中这一项如果异常高，说明瓶颈偏向元数据侧。
• blockcache的read：对同一个固定文件反复读时，如果仍持续有本地缓存读流量，说明读请求没有进入 page cache，文档提示可从这个方向排查（例如内存不足）。
• object的get/put：对象存储读写带宽。启用缓存时，穿透到对象存储会明显拖慢读性能，可用这一项确认数据是否已被缓存；把object.get与fuse.read对比，可以大致看出当前的读放大情况。

文档没有给出 fio 结果的固定通过阈值：判定方式就是上面这套"fio 字段 + stats 指标"的对照，以及与自己基线环境的比较。

限制与收尾

• 禁用 Trash 的改动作用于整个文件系统，测试期间写入/删除的临时文件会真正释放空间；测试结束按需恢复--trash-days保留天数。
• 测试会在挂载点下生成数 GiB 的临时测试文件（--size× 线程数），确认测试目录所在的空间与配额。
• 想换 IO 引擎、并发数或 IO 粒度时，参考可选章节的 libaio 变体；两条命令路径（fio.md 与性能评估指南）是各自独立的测试配置，参数不同，不要混用同一组参数解读。

【免费下载链接】juicefsJuiceFS is a distributed POSIX file system built on top of Redis and S3.项目地址: https://gitcode.com/GitHub_Trending/ju/juicefs