使用 fio 对 JuiceFS 进行顺序读写基准测试方法与结果解读【免费下载链接】juicefsJuiceFS is a distributed POSIX file system built on top of Redis and S3.项目地址: https://gitcode.com/GitHub_Trending/ju/juicefs本文基于 JuiceFS 官方基准测试文档介绍如何使用 fio 在 JuiceFS 与 AWS EFS、S3FS 上执行顺序读/顺序写基准测试涵盖测试环境搭建、挂载配置、fio 参数详解与结果分析帮助读者复现一套可横向对比的 POSIX 文件系统性能测试流程。读完本文你将掌握从「关闭回收站」到「多任务并发 fio 测试」的完整基准测试方法并能结合仓库源码理解 JuiceFS 相关挂载参数对吞吐的影响。测试前的必要准备关闭回收站JuiceFS v1.0 默认启用了回收站功能。基准测试会在文件系统中反复创建和删除临时文件这些被删除的文件并不会立即释放存储空间而是会被转存到文件系统根目录下的.trash目录中按照回收站的保留策略占用对象存储空间直到后台任务将其真正清理。为了避免测试产生的临时文件大量堆积在.trash中占用存储建议在基准测试之前临时关闭回收站juicefs config META-URL --trash-days 0其中META-URL是文件系统的元数据引擎地址例如redis://localhost/1或sqlite3:///path/to/myjfs.db。根据 command_reference.mdx 的说明--trash-days控制已删除文件在回收站内保留的天数默认值为 1设为 0 即禁用回收站。测试结束后如需恢复默认行为再次执行juicefs config META-URL --trash-days 1即可。需要注意的是回收站文件的实际清理依赖 JuiceFS 客户端的后台任务background job执行即使设置了保留天数清理也不是即时的关闭回收站则能确保测试产生的删除操作直接生效不留下任何历史包袱。测试方法与测试工具本文档描述的基准测试方法为使用 fio 在三个文件系统上执行顺序读和顺序写基准测试JuiceFS元数据存于本地 Redis数据存于 Amazon S3AWS EFSAWS 托管的 NFS 文件系统S3FS基于 FUSE 将 S3 桶挂载为本地目录的开源工具。以下测试使用的工具为fio 3.1。fio 通过--rw参数区分读写模式read/write为顺序读 / 顺序写通过--numjobs控制并发任务数是业界标准的工作负载模拟工具。顺序读测试任务数1对三个文件系统分别执行单任务顺序读测试读取 4 GiB 大小的文件每次 IO 块大小为 4 MiBfio --namesequential-read --directory/s3fs --rwread --refill_buffers --bs4M --size4G fio --namesequential-read --directory/efs --rwread --refill_buffers --bs4M --size4G fio --namesequential-read --directory/jfs --rwread --refill_buffers --bs4M --size4G顺序写测试任务数1写测试相比读测试增加了--end_fsync1确保写入完成后调用fsync将数据真正落盘避免数据停留在操作系统页缓存中虚增成绩fio --namesequential-write --directory/s3fs --rwwrite --refill_buffers --bs4M --size4G --end_fsync1 fio --namesequential-write --directory/efs --rwwrite --refill_buffers --bs4M --size4G --end_fsync1 fio --namesequential-write --directory/jfs --rwwrite --refill_buffers --bs4M --size4G --end_fsync1顺序读测试任务数16通过--numjobs16将并发任务数提升到 16考察多任务并行下的聚合吞吐能力fio --namebig-file-multi-read --directory/s3fs --rwread --refill_buffers --bs4M --size4G --numjobs16 fio --namebig-file-multi-read --directory/efs --rwread --refill_buffers --bs4M --size4G --numjobs16 fio --namebig-file-multi-read --directory/jfs --rwread --refill_buffers --bs4M --size4G --numjobs16顺序写测试任务数16fio --namebig-file-multi-write --directory/s3fs --rwwrite --refill_buffers --bs4M --size4G --numjobs16 --end_fsync1 fio --namebig-file-multi-write --directory/efs --rwwrite --refill_buffers --bs4M --size4G --numjobs16 --end_fsync1 fio --namebig-file-multi-write --directory/jfs --rwwrite --refill_buffers --bs4M --size4G --numjobs16 --end_fsync1fio 参数速查参数含义本文取值--name测试任务名称会体现在测试文件名中sequential-read/big-file-multi-write等--directory测试文件所在目录对应各文件系统的挂载点/s3fs、/efs、/jfs--rwIO 模式read/write为顺序读 / 顺序写read、write--refill_buffers每次 IO 前重新填充数据缓冲区避免使用重复数据1启用--bs单次 IO 块大小4M--size每个任务job的 IO 总大小即测试文件大小4G--numjobs并发任务数1 或 16--end_fsync任务结束时执行fsync确保数据落盘1启用关于 fio 更多参数的语义如--ioengine、--direct等可参考仓库中的性能评估指南其中有对随机读写的补充测试示例。测试环境以下测试结果均使用 fio 在亚马逊云 c5d.18xlarge EC2实例上得出实例规格与软件版本如下项目配置实例类型c5d.18xlarge72 CPU144 GiB RAM操作系统Ubuntu 18.04 LTSKernel 5.4.0fio3.1JuiceFS 元数据引擎同主机本地 Redisversion 4.0.9JuiceFS 对象存储Amazon S3S3FSversion 1.82JuiceFS 挂载命令./juicefs format --storages3 --buckethttps://BUCKET.s3.REGION.amazonaws.com localhost benchmark ./juicefs mount --max-uploads150 --io-retries20 localhost /jfsformat命令创建名为benchmark的文件系统元数据引擎为本地 Redislocalhost数据存储到指定的 S3 桶mount命令将文件系统挂载到/jfs。这里针对高吞吐顺序读写场景调大了两个关键参数--max-uploads150上传并发数。默认值为 20见 cmd/flags.go顺序写大文件时提高上传并发可以让更多数据块并行上传到 S3从而提升写入吞吐--io-retries20网络异常时的重试次数同时控制元数据请求的重试次数。默认值为 10见 cmd/flags.go在网络波动时更高的重试上限有助于保证长时基准测试的稳定性。从源码看这两个参数在挂载时会分别落入数据层与元数据层的配置max-uploads被写入 chunk 层的MaxUpload字段控制上传连接的并发数io-retries同时被写入对象存储层的MaxRetries和元数据层的conf.Retries见 cmd/mount.go这印证了「既影响数据上传重试、也影响元数据请求重试」的行为。更多选项说明可参考 mount 通用选项。EFS 挂载命令与 AWS 配置说明一致使用 NFSv4.1 协议挂载mount -t nfs -o nfsvers4.1,rsize1048576,wsize1048576,hard,timeo600,retrans2,noresvport, EFS-ID.efs.REGION.amazonaws.com:/ /efs关键挂载选项nfsvers4.1指定 NFS 版本rsize/wsize设为 10485761 MiB以匹配大块 IOhard表示 NFS 请求失败时持续重试而不是返回错误timeo600与retrans2控制超时与重传行为noresvport禁用保留端口避免 NFS 客户端重连时端口冲突。S3FS 挂载命令s3fs BUCKET:/s3fs /s3fs -o hosthttps://s3.REGION.amazonaws.com,endpointREGION,passwd_file${HOME}/.passwd-s3fshost与endpoint指定 S3 服务地址与区域passwd_file指向包含 Access Key / Secret Key 的凭据文件格式为AWS_ACCESS_KEY_ID:AWS_SECRET_ACCESS_KEY。测试结果三套文件系统在上述环境下的顺序读写基准测试结果如下图所示结合 fio 输出的bw带宽字段可对比各文件系统的顺序读 / 顺序写吞吐能力。需要说明的是本图数据来自上述特定测试环境c5d.18xlarge 本地 Redis吞吐表现会随实例规格、网络带宽、对象存储性能、挂载参数的不同而变化复现时应以自身环境实测为准。结合源码理解基准测试JuiceFS 内置的juicefs bench除了使用 fio 这类通用工具JuiceFS 还自带了juicefs bench命令用于快速完成单机基准测试并给出绿 / 黄 / 红三色健康度提示实现见 cmd/bench.gojuicefs bench /mnt/jfs -p 4其测试流程见 cmd/bench.go包括N 并发写大文件 → 读大文件 → 写小文件 → 读小文件 → stat 小文件 → 清理临时目录并可通过-p指定并发线程数、--block-size/--big-file-size/--small-file-size等参数定制负载。它可以作为 fio 测试前的快速体检如果 bench 结果出现红色指标说明环境配置可能存在问题应优先排查后再进行 fio 这类更复杂的测试。完整流程说明可参考性能评估指南。顺序写吞吐的关键因素从架构上看JuiceFS 的顺序写性能与--max-uploads、--buffer-size等参数密切相关。仓库文档在 读写缓冲区 一节指出对于 4 MiB 粒度的写入模式20 并发已是较高的默认值进一步提高写并发往往需要同步增大--buffer-size否则并发上传会因缓冲区不足而产生排队阻塞反而恶化写入速度。因此本文测试环境将--max-uploads调至 150 的同时通常也需要配合充足的读写缓冲区配置。一个实用的验证思路如果你怀疑测试结果受本地缓存影响可以像 cmd/bench.go 的实现一样在每轮测试间清理内核页缓存Linux 下通过echo 3 /proc/sys/vm/drop_caches需要 root 权限确保读测试真正从对象存储读取数据而非命中系统缓存从而得到更接近真实性能的数值。总结本文完整复现了 JuiceFS 官方文档中基于 fio 3.1 的顺序读 / 顺序写基准测试方案测试前先通过juicefs config META-URL --trash-days 0关闭回收站避免临时文件堆积随后在 JuiceFS、EFS、S3FS 三个文件系统上分别执行 1 任务与 16 任务并发的大文件顺序读写测试测试环境采用 c5d.18xlarge 实例、本地 Redis 存储元数据、S3 存储数据并通过调大--max-uploads与--io-retries优化 JuiceFS 挂载配置。掌握这套方法后你可以将其扩展到随机读写、小文件 IO、混合负载等更多场景参考性能评估指南中的 Vdbench 多机测试与随机读写 fio 示例结合juicefs bench、juicefs stats等内置工具系统评估 JuiceFS 在目标工作负载下的性能表现并为生产部署的参数调优提供依据。【免费下载链接】juicefsJuiceFS is a distributed POSIX file system built on top of Redis and S3.项目地址: https://gitcode.com/GitHub_Trending/ju/juicefs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考