Skip to main content

JuiceFS 性能数据参考

基准性能​

顺序读​

规格：48c|192G|36Gbps

软件系统：Ubuntu 22.04，FIO：3.7，JuiceFS 5.2

fio --name=seqread_bigfile     --filename=/jfs/bigfile-10G     --rw=read     --bs=1M     --size=10G   --iodepth=1     --numjobs={thread_num}       --group_reporting  --direct=1 --time_based --runtime=120

顺序读吞吐量图表

  • JuiceFS 单线程带宽可以达到 2.4 GiB/s
  • 随着线程的增加，带宽可以实现近线性增长，在 20 线程时达到了顶峰 25.1 GiB/s
  • 缓存采用本地内存以规避磁盘吞吐瓶颈影响极值吞吐
  • CPU 消耗在每 GB/s - 1～1.5 核左右，到达 25GiB/s 大概在 30～40 核之间波动。

随机读​

JuiceFS 测试规格：32c|64G|40Gbps

软件系统：Ubuntu22.04，FIO：3.7，JuiceFS 5.4

GPFS 对比测试规格：96c|384G|400Gbps * 2 RoCE，I/O 节点上执行，全闪盘。

单进程​

fio --name=jfs-randread --filename=/{mnt}/readfile --rw=randread --bs=4k --size=10g --time_based --runtime=20s --time_based --ramp_time=2s --verify=0  --group_reporting=1  --ioengine=libaio  --direct=1 --numjobs=1 --iodepth={x}

随机读单进程图表

  • 单并发情况下 JuiceFS 在 iodepth=8 时达到最大为 68K IOPS，iodepth=16 开始衰减并在 iodepth=64 逐渐企稳
  • GPFS 在 iodepth=16 表现最佳为 83K IOPS
  • tmpfs 的底层为云盘，采用本地 NVMe 的话性能会更好，此处仅为使用一个本地文件系统作为分布式/并行文件系统的随机读的对比参考

多进程（iodepth 固定为 8）​

fio --name=jfs-randread --filename=/{mnt}/readfile --rw=randread --bs=4k --size=10g --time_based --runtime=20s --time_based --ramp_time=2s --verify=0  --group_reporting=1  --ioengine=libaio  --direct=1 --iodepth=8 --numjobs={x}

随机读多进程图表

  • 多进程随机读单一文件时 JuiceFS 表现优异，在 12 并发时出现瓶颈，最高 258K IOPS，延迟始终在 0.4ms 左右
  • GPFS 多进程读单一文件因锁竞争消耗多，在 2 进程以上开始出现明显衰减。所以加测一种方式，为每个 FIO 读不同的文件以规避锁竞争及元数据 token 争抢问题。JuiceFS 在这两种方式下性能表现一致所以无需调整。
  • tmpfs 应是达到了云盘的吞吐上限（200MB/s），一直在 50K IOPS 徘徊

顺序写​

规格：48c|192G|36Gbps，5 台。

软件系统：Centos7.9，FIO：3.7，JuiceFS 5.2

对象存储最大写带宽 200Gbps

顺序写吞吐量图表

  • JuiceFS 直接写对象存储，依赖对象存储提供带宽，多并发情况下可以轻松打满网络带宽
  • 多机情况下聚合吞吐呈线性增长，5 台节点聚合到 21.4GiB/s 的写带宽

随机写​

规格：64c|128G|40Gbps。

软件系统：Ubuntu 22.04，JuiceFS 5.2

GPFS 测试规格：96c|384G|400Gbps * 2 RoCE，I/O 节点上执行，全闪盘。

为规避多进程随机写同一文件的竞争锁问题，每个 FIO 进程都写自己单独的文件

fio --name=randwrite    --directory=/{mnt}    --filename_format=file.\$jobnum    --size=512M    --bs=4k    --rw=randwrite     --iodepth=1   --ioengine=libaio      --direct=1    --time_based    --runtime=20    --group_reporting --numjobs={x}

随机写 IOPS 图表

  • JuiceFS 最高在 57K 的 4K 随机写性能
  • JuiceFS 采用 writeback 挂载，并且 cache-dir 设置为本地的 nvme 盘路径
  • GPFS 在单并发时性能不高，但可以做到线性扩容，在 12 并发时追平并超过 JuiceFS
  • JuiceFS 在随机写之后还会占用一定的时间和带宽资源做对象存储上的碎片整理

元数据基准性能​

JuiceFS 企业版采用自研元数据引擎，基于 Raft 的纯内存无锁实现方案，利用多个分区提供极低请求延迟的同时可以做到容量的线性扩容，性能的近线性扩容。

服务节点规格：30c|120G|25Gbps

软件系统：Ubuntu 22.04，JuiceFS 5.3 元数据服务

OperationQPS (k/s)
getattr90
lookup18.4
setattr29
mkdir60
readdir3.7
create54
write48
read182
rename40
hardlink37.5
  • JuiceFS 企业版默认是单个 Raft 分区提供服务，以上是单分区的元数据性能
  • 多台元数据节点可以混部多个分区，性能呈近线性增长（除了 readdir 和 lookup 之外）

集群压测性能（TCP）​

JuiceFS 在 GCP 上 100 节点聚合压测 I/O 吞吐

服务节点规格：32c | 128G | 100Gbps * 100 台聚合测试

软件系统：Ubuntu 22.04，JuiceFS 5.2

提示

JuiceFS 在 100 台缓存节点上压测结果：1.23 TB/s，带宽利用率 98%

我们在 GCP 上申请了 100 台 32 核 128G 内存以及 100Gbps 网卡的虚拟机，每台都带上 2 块 3.84TiB 的 NVMe 盘。为了打满 100Gbps 的网卡带宽不让磁盘成为瓶颈，我们每台机器混合了 50% 的内存作为缓存池，这样 2 块 NVMe 盘 + 内存就可以稳定提供打满节点 100Gbps 的上行带宽的能力，不让存储成为单台缓存节点的瓶颈。

同时这 100 台节点也作为业务消费节点来使用分布式缓存（即点对点模式），证实了在 GCP 上（100Gbps 以太网全双工网卡），JuiceFS 可以做到几乎打满每台机器的 100Gbps 上下行带宽读写。这归功于：

  • 企业版的分布式缓存使用一致性哈希算法，尽可能均衡数据块到所有节点上，分散热点。
  • 优化零拷贝和多路复用算法，有效降低额外吞吐折损，以及降低 CPU 消耗。

集群压测性能（RDMA）​

JuiceFS 5.3 引入了 RDMA 支持，

缓存节点：

128C｜500G｜IB 400Gbps * 4｜10 块 NVMe 的磁盘 * 3 台，理论最高提供 300GB/s 的分布式缓存吞吐

客户端节点：

128C｜500G｜IB 400Gbps * 2｜带宽充裕但由于 FUSE 限制，单台最多获得 60GB/s 的下载速度，需要多机打满服务端发送带宽

顺序读​

FIO 多并发顺序读命令：

fio --name=seq --directory=/jfs --filename_format=file.\$jobnum.dat --size=1G --bs=1M --rw=read --numjobs=36 --iodepth=1 --ioengine=libaio --direct=1 --time_based --runtime=2000 --group_reporting

RDMA 顺序读吞吐图表

说明：

  • RDMA 网卡利用率（平均）高达 96%，在总共 400Gbps*6 的聚合带宽条件下，提供了 288GB/s 的平均带宽。（*图 1）
  • FUSE 客户端目前 RDMA 能测到的单机吞吐极值为 60GB/s，相比 TCP 的 25GB/s 提升了一倍有余，但再加压且哪怕两个挂载点也无法继续提升总吞吐
  • 显示聚合吞吐值为全部测试的平均值，如 6 节点客户端最高到过 300 多 GB/s，带宽利用率超过了 100%，但后台监控发现此时的缓存节点总发送带宽也超过了 400Gbps*2，所以取「平均」以消除网络波动也最贴近业务实感（*图 2）
  • 缓存服务端介质为本地 10*NVMe+1*系统盘，单节点满负荷时可以提供最高 91GB/s 的读吞吐（而纯内存只有 48GB/s），基本可以让两块 400Gbps 的网卡打满。（*图 3）
  • RDMA 客户端利用率在 25 核左右徘徊（*图 4）

图 1：平均聚合带宽

图 1：FUSE 客户端单机吞吐测试结果

图 2：业务流量示意图

图 2：Remote Cache 业务流量示意图

图 3：缓存节点磁盘读取流量

图 3：缓存节点磁盘读取流量

图 4：RDMA 客户端 CPU 利用率

图 4：RDMA 客户端 CPU 利用率

JuiceFS vs 3FS vs WEKA​

对比项3FSWEKAJuiceFS
存储节点数18080100
计算节点数500+存储与计算融合存储与计算融合
网络2×200 Gbps IB / 存储节点；1×200 Gbps IB / 计算节点RDMA 100 Gbps RoCE100 Gbps 以太网
存储介质16×14 TiB NVMe SSD / 节点1×3.84 TiB NVMe / 节点2×3.84 TiB NVMe / 节点
总吞吐量（大块读）6.6 TiB/s（38 GB/s/服务器）575 GB/s（7.19 GB/s/服务器）1.23 TB/s（12.3 GB/s/服务节点）
带宽利用率54%（按计算节点算）75%（按存储节点算）58%98%

3FS 数据来自 Deepseek 公开的论文或 GitHub 仓库（github.com/deepseek-ai/3FS）

WEKA 数据来自 Oracle 官方博客（WEKA 在 OCI 上的官方基准测试：weka-on-oracle-cloud-infrastructure-delivers-2-terabytes-per-second-performance）

客户实际生产表现性能​

下方性能数据是客户真实业务运行带来的 JuiceFS 表现，不代表极限性能。

某智驾客户​

某智驾客户生产环境 I/O 吞吐（读峰值 621 GB/s）

某智驾客户生产环境聚合 IOPS（峰值 5.06M）

某智驾客户分布式缓存出向带宽（1.02 TB/s）

生产环境性能全景​

智驾企业生产环境中 JuiceFS 的性能表现，生产环境运行 JuiceFS 企业版已达 12 个月以上。

系统规模​

信息
  • 文件系统总容量：30 PB
  • 文件数量（inodes）：4 亿
  • 客户端计算节点：7,480 台
  • 分布式缓存节点：135 台
  • 分布式缓存容量：4.7 PB

核心性能指标​

提示
  • 聚合 I/O 吞吐：621 GB/s；聚合 IOPS：5.06 M；读多写少，以大块读为主
  • 分布式缓存出向带宽：1.02 TB/s

某 LLM 训练客户​

LLM 企业使用 JuiceFS 支撑预训练 + 后训练全流程业务。

系统规模​

信息
  • 数据总量：10+ PiB
  • 文件数量：2 亿+
  • 平均文件大小：60 MiB
  • 客户端节点：883 台

核心性能指标​

提示
  • 元数据 QPS：最高 7.45 万/s，平均响应时间仅 560 µs
  • 整体读吞吐：最高 186 GB/s，均值 6.15 GB/s
  • 整体写吞吐：最高 19.4 GB/s，均值 1.21 GB/s
  • 缓存集群（Remote Cache）读吞吐：最高 325 GB/s，均值 18.8 GB/s

某 AI 模型训练客户​

该客户使用 JuiceFS 主要是利用分布式缓存加速训练过程。准备了 139 台机器，每台提供 52TB 缓存容量及 40Gbps 的 IP 网卡。理论最大应可支持 695GB/s 的吞吐量。下图所见基本跑满了：

缓存客户端聚合从缓存池里读取的吞吐

上图表示缓存客户端聚合从缓存池里读取的吞吐

实际业务读取存储获得的吞吐量

上图表示实际业务读取存储获得的吞吐量

得益于智能预读机制，缓存集群的读出流量会高于业务实际消费的有效数据量，这是预读命中后的正常现象。相比直读对象存储，缓存读吞吐提升数十倍，显著加速了模型训练的数据读取效率，符合客户使用预期。

最后于 更新
在 X 上关注我们
在 Discord 上交流
加入微信用户群