JuiceFS 性能基准测试实战bench 命令、fio 吞吐测试与 mdtest 元数据 IOPS 评估【免费下载链接】juicefsJuiceFS is a distributed POSIX file system built on top of Redis and S3.项目地址: https://gitcode.com/GitHub_Trending/ju/juicefs本文以 JuiceFS 官方性能基准文档为主线讲解如何评估一套分布式文件系统环境的真实性能先使用内置的juicefs bench子命令快速体检环境再用 fio 压测顺序读写吞吐用 mdtest 压测元数据 IOPS并结合juicefs stats与juicefs profile做性能分析。读完后你应能独立完成一轮 JuiceFS 端到端基准测试读懂测试工具输出并依据源码理解每项指标的统计口径。一、为什么要做基准测试以及基准测试前的注意事项JuiceFS 是构建在元数据引擎如 Redis与对象存储如 S3之上的 POSIX 分布式文件系统。由于最终性能取决于元数据引擎、对象存储、网络带宽、客户端配置等多方因素官方文档Performance Benchmark给出的结论是在 Redis 作为元数据引擎的条件下进行基准测试可以定量回答“我的环境配置是否正常”“瓶颈在元数据还是对象存储”这两个问题。在开始压测前官方文档特别提示了一个容易踩的坑JuiceFS v1.0 默认启用回收站Trash。基准测试过程中会在文件系统中创建并删除大量临时文件这些文件最终会落入.trash目录并占用存储空间。为避免该问题可以在压测前执行juicefs config META-URL --trash-days 0关闭回收站。这一点在 fio 测试文档 与 mdtest 测试文档 开头均有相同提示。另外cmd/bench.go中的单元测试cmd/bench_test.go也印证了这一点——TestBench在挂载临时测试文件系统时显式传入了--trash-days0。二、juicefs bench一条命令完成基础性能体检bench是 JuiceFS 内置的子命令用于在目标路径上运行一组基础基准测试快速验证文件系统在当前环境是否工作正常。其命令定义位于 cmd/bench.go源码中的命令说明为Run basic benchmarks on the target PATH to test if it works as expected. Results are colored with green/yellow/red to indicate whether they are in a normal range. If you see any red value, please double check relevant configuration before further test.2.1 参数说明从cmd/bench.go的cmdBench()函数可以看到完整的参数列表与默认值参数默认值说明PATH必填测试目录挂载点内的任意目录实际测试会在其下创建__juicefs_benchmark_时间戳__临时目录--block-size1M每个 IO 块大小MiB--big-file-size1G每个大文件大小MiB设为0可跳过大文件测试--small-file-size128K每个小文件大小KiB--small-file-count100每线程的小文件数量--threads/-p1并发线程数官方建议设置为服务器 CPU 核数基本用法示例与源码 Description 及 性能评估指南 一致# 使用 4 个并发线程运行基准测试 juicefs bench /mnt/jfs -p 4 # 只测试小文件跳过大文件测试 juicefs bench /mnt/jfs --big-file-size 02.2 测试流程源码级拆解从 cmd/bench.go 的bench()函数实现看整个流程为预检查解析block-size、文件大小参数在目标路径下创建带纳秒时间戳的临时目录__juicefs_benchmark_%d__通过findMountpoint定位所属挂载点清理内核缓存Linux 下执行echo 3 /proc/sys/vm/drop_cachesmacOS 下执行purge且非 root 用户会自动加sudo前缀每一轮大文件写、大文件读、小文件写、小文件读、stat 之间都会再次清理缓存保证读测试真实命中对象存储/缓存层而不是页缓存设置环境变量SKIP_DROP_CACHEStrue可跳过该操作单测即以此方式运行运行基准N 为--threads的并发数N 并发写每线程一个 1 GiB 大文件IO 尺寸 1 MiBwriteFiles按block-size分块随机数据utils.RandRead填充后循环fp.WriteN 并发读读回刚写的大文件readFilesN 并发写每线程 100 个 128 KiB 小文件N 并发读读回 100 个小文件N 并发 stat对 100 个小文件逐个os.Stat清理与报告rm -rf删除临时目录Windows 用rd /s /q打印结果表格并输出测试期间的耗时、CPU 占用、内存用量。并发通过sync.WaitGroup goroutine 实现见benchCase.run()每线程写入的文件命名为{bigfile|smallfile}.{线程号}.{序号}天然避免线程间文件竞争。2.3 如何解读结果红黄绿三色机制bench的输出为三列表格ITEM测试项、VALUE吞吐/每秒文件数/每秒操作数、COST每文件或每操作耗时。源码 cmd/bench.go 中预置了resultRange阈值表每项指标对应[min, max, cost_min, cost_max]四个界var resultRange map[string][4]float64{ bigwr: {100, 200, 10, 50}, // 大文件写吞吐 MiB/s bigrd: {100, 200, 10, 50}, // 大文件读吞吐 MiB/s smallwr: {12.5, 20, 50, 80}, // 小文件写 files/s smallrd: {50, 100, 10, 20}, // 小文件读 files/s stat: {20, 1000, 1, 5}, // stat files/s fuse: {0, 0, 0.5, 2}, // FUSE 操作 ms/op meta: {0, 0, 2, 5}, // 元数据事务 ms/op put: {0, 0, 100, 200}, // 对象 PUT ms/op get: {0, 0, 100, 200}, // 对象 GET ms/op delete: {0, 0, 30, 100}, // 对象 DELETE ms/op cachewr: {0, 0, 10, 20}, // 写缓存 ms/op cacherd: {0, 0, 1, 5}, // 读缓存 ms/op }判色逻辑colorize()吞吐量高于max为绿色、介于min与max之间为黄色、低于min为红色延迟低于cost_min为绿色、高于cost_max为红色。对smallwr/smallrd/stat三项吞吐量阈值会乘以线程数bm.threads即并发越多期望吞吐按比例放大。出现红色指标时应先检查相关配置网络、元数据引擎距离、对象存储带宽、max-uploads等再决定是否继续后续测试。2.4 深入项从 Prometheus 指标拆解 FUSE/元数据/对象存储延迟当目标路径是 JuiceFS 挂载点时bench会在测试前后两次调用readStats(mp)抓取 Prometheus 指标用差值计算以下七项延迟对应源码中show()的调用报告项底层指标FUSE operationfuse_ops_durations_histogram_secondsUpdate metatransaction_durations_histogram_secondsPut / Get / Delete objectobject_request_durations_histogram_seconds_PUT/_GET/_DELETEWrite into cache / Read from cacheblockcache_write_hist_seconds/blockcache_read_hist_seconds这使得一次bench不仅能给出端到端吞吐还能定位慢在哪一层FUSE 层内核交互与客户端开销、元数据事务、对象存储请求还是本地块缓存。此外元数据引擎基准文档 展示了同一张表在 Redis、MySQL、PostgreSQL、TiKV、etcd、FoundationDB 六种元数据引擎下的实测对比——例如大文件写吞吐各家均在 730~746 MiB/s 区间对象存储成为瓶颈而Stat file在 Redis 下约 12000 files/sMySQL 下约 3583 files/s直观体现了元数据引擎对元数据密集负载的影响。三、fio 顺序读写吞吐测试官方基准使用 fio版本 3.1在 JuiceFS、Amazon EFS 与 S3FS 三者之间做顺序读写吞吐对比。完整的测试方案、命令与环境见 docs/en/benchmark/fio.md此处完整保留其测试命令顺序读单任务fio --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顺序写单任务测试结束 fsyncfio --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_fsync116 任务并发顺序读/写在上述命令基础上追加--numjobs16写测试保留--end_fsync1用于考察多客户端/多线程并发下的聚合吞吐。3.1 测试环境三组测试均在 EC2 c5d.18xlarge 实例72 vCPU144 GiB 内存 Ubuntu 18.04 LTSKernel 5.4.0上执行JuiceFS 使用本地 Redis 4.0.9 存储元数据挂载命令为./juicefs format --storages3 --buckethttps://BUCKET.s3.REGION.amazonaws.com localhost benchmark ./juicefs mount --max-uploads150 --io-retries20 localhost /jfs其中--max-uploads与--io-retries是 JuiceFS 挂载级参数定义见 cmd/flags.go在 cmd/mount.go 中分别映射到conf.MaxUpload与conf.Retries前者控制并发的上传任务数上限直接影响大块写入对象存储的并发带宽后者控制 IO 失败重试次数影响弱网下的稳定性。EFS 使用 NFS v4.1 挂载rsize/wsize1048576,hard,timeo600,retrans2,noresvportS3FS 使用 1.82 版本通过passwd_file提供凭证。3.2 测试结果官方结论在该环境Redis 元数据 S3 对象存储 大规格 EC2 客户端下JuiceFS 的顺序读写吞吐约为 EFS 与 S3FS 的 10 倍需要说明该结论的适用前提测试客户端是 72 vCPU / 144 GiB 的大规格实例且对象存储带宽充足小规格实例或带宽受限环境下三者差距会缩小。性能评估指南 同时提示大文件顺序吞吐是 JuiceFS 的优势项但小文件写入性能相对一般因为每个文件都要持久化到对象存储而对象存储 API 调用通常有 10~30ms 的固定开销。该指南还给出了更贴近日常使用的 fio 参数说明--ioenginelibaio、--direct1关闭系统缓冲使结果更稳定等以及随机读写示例可直接复用# 顺序写libaio O_DIRECT fio --namejfs-test --directory/mnt/jfs --ioenginelibaio --rwwrite --bs1m --size1g --numjobs4 --direct1 --group_reporting # 随机读 fio --namejfs-test --directory/mnt/jfs --ioenginelibaio --rwrandread --bs1m --size1g --numjobs4 --direct1 --group_reporting四、mdtest 元数据 IOPS 测试元数据操作create / stat / unlink 等是分布式文件系统与本地文件系统差异最大的部分。官方基准使用 HPC 社区的 mdtest3.4 版本在 JuiceFS、EFS、S3FS 之间对比元数据 IOPS完整方案见 docs/en/benchmark/mdtest.md。为控制在 5 分钟内跑完参数做了相应调整./mdtest -d /s3fs/mdtest -b 6 -I 8 -z 2 ./mdtest -d /efs/mdtest -b 6 -I 8 -z 4 ./mdtest -d /jfs/mdtest -b 6 -I 8 -z 4测试环境为 EC2 c5.large2 vCPU4 GiBRedis 4.0.9 运行在同可用区的 c5.large 实例上。JuiceFS 侧仅两条命令./juicefs format --storages3 --buckethttps://BUCKET.s3.REGION.amazonaws.com localhost benchmark nohup ./juicefs mount localhost /jfs 官方结论JuiceFS 的元数据 IOPS 显著高于 EFS 与 S3FS4.1 官方原始输出摘录mdtest 文档 保留了三者的完整 SUMMARY rateops/sec均值单任务。关键对比行操作S3FSEFSJuiceFSDirectory creation5.977192.3011416.582Directory stat435.8981311.1663810.083File creation5.696179.2931410.288File stat68.692915.2305023.227File readopen/close33.931371.0123487.947File removal23.658217.4981163.371从数字量级看该次测试中 JuiceFS 元数据速率约为 EFS 的 7~8 倍、S3FS 的 20~70 倍不同操作倍数不一。注意 S3FS 的-z 2与其余两者的-z 4不同即 S3FS 测试的目录树更浅、文件数更少344 个 vs 12440 个对比时以相对量级而非绝对值为准。4.2 仓库内置的元数据压测命令juicefs mdtest除外部 mdtest 工具外JuiceFS 源码中还内置了一个直接压测元数据引擎的子命令cmd/mdtest.go标记为Hidden不进入主帮助列表其用法为juicefs mdtest redis://localhost /test1参数包括--threads默认 1、--dirs默认 3子目录数、--depth默认 2目录树层级、--files默认 10文件数、--write写入字节数默认 0 即只测纯元数据。从runTest()的实现看它会先构建目录树并统计 dirs/s再以多线程createFile递归创建文件并统计 files/s当--write大于 0 时还会通过meta.NewSlicem.Write真实写入 chunk 数据。这意味着可以直接对元数据引擎做脱离客户端 FUSE 层的裸压测适合在多节点环境下评估元数据引擎的扩展能力——元数据引擎基准文档 中的并行 mdtest 测试正是用mpirun -np 12在 3 个客户端节点上执行# 纯元数据 mpirun --use-hwthread-cpus --allow-run-as-root -np 12 --hostfile myhost --map-by slot /root/mdtest -b 3 -z 1 -I 100 -u -d /mnt/jfs # 12000 个 100KiB 小文件 mpirun --use-hwthread-cpus --allow-run-as-root -np 12 --hostfile myhost --map-by slot /root/mdtest -F -w 102400 -I 1000 -z 0 -u -d /mnt/jfs五、性能分析stats 与 profile 工具当基准测试暴露出性能问题时官方基准文档指向实时性能监控章节。性能评估指南 给出了两个配套工具的标准用法5.1juicefs stats实时指标观测类似 Linux 的dstat在juicefs bench运行期间另开一个会话执行juicefs stats /mnt/jfs --verbosity 1即可实时看到客户端吞吐、缓存命中、元数据延迟等指标变化与 bench 的测试流程大文件写 → 大文件读 → 小文件读写 → stat对照着看能直接判断当前处于哪一阶段、瓶颈在哪一层。5.2juicefs profile访问日志回放统计.accesslog是 JuiceFS 挂载点内的一个虚拟文件只有被读取如cat时才会产生日志cat /mnt/jfs/.accesslog juicefs.accesslog # CtrlC 停止后 juicefs profile juicefs.accesslog --interval 0--interval 0表示快速回放整个日志文件生成统计。官方指南中给出了一个非常有助于理解调用链的推算默认参数下 bench 共创建(1 100) × 4 404个文件每个文件经历 Create → Write → Close → Open → Read → Close → Delete 全流程因此应有 404 次 create/open/unlink、808 次 flushclose 自动触发、以及 33168 次 write/read 请求——因为 FUSE 层单次请求默认最大 128 KiB1 GiB 大文件按 1 MiB 应用层 IO 拆成 8 个 FUSE 请求(1024 × 8 100) × 4 33168。这与 profile 统计完全吻合。指南还指出write平均延迟极低约 45 μs的原因JuiceFS 默认先把写入放进内存缓冲close 时再经 flush 上传对象存储。六、测试后端对象存储juicefs objbench文件系统级测试只能看到“组合性能”要评估对象存储本身是否配得上 JuiceFS带宽是否够、功能是否齐全可用内置的 objbench 子命令单独压测对象存储端juicefs objbench \ --storage s3 \ --access-key myAccessKey \ --secret-key mySecretKey \ https://mybucket.s3.us-east-2.amazonaws.com从源码看objbench先执行 15 项功能测试建桶、上传/下载对象、Range 读、HEAD、DELETE、List、分片上传、chown、chmod、修改 mtime 等不支持的功能标记为not support再执行 10 项性能测试上传/下载小对象并校验内容、分片上传大对象、并发 List、并发取元信息/改 mtime/改权限/删除等。可调参数包括--threads/-p默认 4、--block-size默认 4M、--big-object-size默认 1G、--small-object-size默认 128K、--small-objects默认 100、--shards按 key 哈希分桶以及--skip-functional-tests。测试结果中任何一项failed都提示该对象存储与 JuiceFS 的兼容性存在问题。七、把基准测试组织成可复现的评估流程综合以上文档一个可落地的完整流程是明确场景参照 性能评估指南应用类型Spark / PyTorch / 自研程序、所需 CPU/内存/网络规格、数据规模文件数与总容量、文件粒度与访问模式大/小文件顺序/随机、量化指标吞吐、QPS、延迟关闭回收站juicefs config META-URL --trash-days 0快速体检juicefs bench /mnt/jfs -p CPU核数红黄绿三色定位异常项定位分层瓶颈juicefs stats实时观测 juicefs profile回放.accesslog专项压测吞吐 → fio顺序/随机--direct1多numjobs元数据 → 外部 mdtest含 mpirun 多节点或内置juicefs mdtest META-URL PATH对象存储后端 →juicefs objbench元数据引擎选型 → 参照 元数据引擎基准 的同环境对比方法Golang Benchmark、bench、mdtest、fio 四件套。记录结论测试场景、参数、环境客户端/元数据/对象存储规格、结果与异常形成可回溯的评估报告。官方各篇文档中的绝对数值如“10 倍于 EFS/S3FS”、各引擎对比倍数均基于特定测试环境实例规格、网络、Redis 版本、对象存储区域复现时请以自身环境实测为准上述数值可用作量级参考与回归对比的基线。【免费下载链接】juicefsJuiceFS is a distributed POSIX file system built on top of Redis and S3.项目地址: https://gitcode.com/GitHub_Trending/ju/juicefs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考