存储分布式文件系统对象存储云原生【免费下载链接】cubefscloud-native distributed storage项目地址https://gitcode.com/gh_mirrors/cu/cubefs点击查看免费下载导读本文档是 CubeFS 元数据性能评估的权威参考基于官方在 v3.3.1 集群环境上使用 mdtest、mdtest 的多进程/多客户端测试脚本以及目录/文件创建、删除、状态查询、树形操作共 8 类操作的吞吐量原始数据并可通过仓库内对应图表直观比对多客户端并发下的性能扩展趋势。读完本文你将能够独立搭建元数据压测环境、解读 CubeFS 元数据节点的扩展能力边界并据此规划生产卷的副本数与分区数量。测试背景与工具说明mdtest 简介mdtest 是 LLNLLawrence Livermore National Laboratory开发的元数据基准测试工具用于评估分布式文件系统在纯元数据操作创建、删除、状态查询、树形目录构建等上的吞吐能力单位为每秒操作数ops/s。它通过 MPImpirun在多个节点上并行发起进程每个进程对独立的目录树执行操作是衡量元数据服务端本项目中即 Metanode性能的主流工具。测试工具参数解析官方测试脚本如下#!/bin/bash TEST_PATH/mnt/cfs/mdtest # mount point of CubeFS volume for CLIENTS in 1 2 4 8 # number of clients do mpirun --allow-run-as-root -np $CLIENTS --hostfile hfile01 mdtest -n 5000 -u -z 2 -i 3 -d $TEST_PATH; done各参数含义与本次取值参数取值说明-n 50005000每个进程创建的文件/目录数量单进程负载规模-u开启仅在唯一unique目录下执行测试避免进程间目录冲突-z 22目录树深度depth用于 Tree Creation / Tree Removal 类测试-i 33迭代次数最终结果为 3 轮迭代的平均值降低抖动-d $TEST_PATH/mnt/cfs/mdtest测试目录即 CubeFS 卷的挂载点--allow-run-as-root开启允许以 root 身份运行 MPI 进程--hostfile hfile01指定MPI 节点主机文件控制进程分布-np $CLIENTS1/2/4/8MPI 进程总数对应客户端进程数脚本外层for CLIENTS in 1 2 4 8依次执行 4 轮对应下文所有表格中的 1/2/4/8 Clients 列每轮内-np进程数与客户端数一致。环境与卷配置前提本次测试复用 环境准备 中的集群3 个管理节点Master、5 个元数据节点Metanode与 5 个数据节点Datanode混合部署均为 80 核、377GiB 内存、4×3.7TiB SSD、50Gb/s 网络。测试卷未设置配额Datanode 未设置流控限速数据/元数据副本数均按推荐值配置详见下文解读与延伸以确保元数据操作不被数据面瓶颈干扰。目录类操作性能ops/s目录类操作直接考验 Metanode 的 dentry 与 inode 管理链路对应源码 dentry.go、partition_op_dentry.go其吞吐随客户端与进程数增加而显著扩展。目录创建Directory Creation1 Process4 Processes16 Processes64 Processes1 Client769.9083630.33712777.61920629.5922 Clients1713.0387259.28224064.05236769.5994 Clients3723.99314002.36642976.83761513.6488 Clients6681.78323946.14364191.3893729.222解读单客户端单进程约 770 ops/s扩展到 8 客户端 × 64 进程时达到约 93,729 ops/s吞吐提升约 121 倍呈现接近线性的扩展趋势。目录删除Directory Removal1 Process4 Processes16 Processes64 Processes1 Client853.9954012.40415238.64742028.8452 Clients1906.2617967.68828410.30862338.5064 Clients3942.59015601.79946741.94587411.6558 Clients7072.08025183.09269054.92379459.091解读目录删除在小规模并发下略优于创建峰值出现在 4 客户端 × 64 进程约 87,412 ops/s8 客户端时因删除需要同步回收 dentry/inode 资源而出现轻微回落。目录状态查询Directory Stat1 Process4 Processes16 Processes64 Processes1 Client462527.4451736760.3326194206.76815509755.8362 Clients885454.3353414538.35212263175.10424951003.4984 Clients1727030.7826874284.76524371306.25010412238.8948 Clients1897588.2147499219.74425927923.6464264896.279解读stat 是纯读操作得益于 Metanode 的 B-tree 内存索引与 FollowerRead 能力单客户端单进程即达约 46 万 ops/s峰值出现在 4 客户端 × 64 进程约 2437 万 ops/s在高并发写密集进程混合时8 客户端 × 64 进程出现回落至约 426 万 ops/s属资源竞争的正常现象。文件类操作性能ops/s文件创建/删除会触发 Metanode 的 inode 分配与 Raft 提交链路核心实现在 partition_op_inode.go 的CreateInodeinode ID 由nextInodeID原子分配后经submit(opFSMCreateInode, ...)提交至 Raft 组。文件创建File Creation1 Process4 Processes16 Processes64 Processes1 Client706.4533306.2709647.17610879.2902 Clients1601.8916601.52219181.96520756.6934 Clients3369.91113165.05636158.06141817.7538 Clients6312.91122560.68755801.06276157.675解读文件创建需要经过 inode 分配、Raft 日志复制与持久化单客户端单进程约 706 ops/s8 客户端 × 64 进程时达到约 76,158 ops/s扩展性良好。文件删除File Removal1 Process4 Processes16 Processes64 Processes1 Client1220.3224606.34011715.45723653.0432 Clients2360.1338971.36122097.20641579.9854 Clients4547.02117242.90034965.47161726.9028 Clients8809.38120379.83955363.38971101.736解读删除操作单点吞吐高于创建约 1220 ops/s在 4 客户端 × 64 进程达到约 61,727 ops/s8 客户端场景受删除后 dentry/inode 回收开销影响增长放缓至约 71,102 ops/s。树形操作性能ops/s树形操作Tree Creation / Tree Removal对应 mdtest 的-z 2深度选项每次操作需在两级目录结构上递归完成单次操作的元数据开销更大因此绝对值低于平铺目录操作但更贴近真实目录树场景。树创建Tree Creation1 Process4 Processes16 Processes64 Processes1 Client734.383379.403146.07037.8112 Clients648.938432.150148.92130.6994 Clients756.639394.733123.72223.9988 Clients607.547263.439124.9117.510解读树创建为递归结构操作增加进程数反而加剧了中间目录的锁竞争与 Raft 提交排队吞吐随进程数增加而下降——这是元数据基准测试中典型的树形结构扩展瓶颈现象。树删除Tree Removal1 Process4 Processes16 Processes64 Processes1 Client552.70683.19723.8235.7472 Clients448.55784.63324.0375.1374 Clients453.52085.63623.4905.2338 Clients429.92083.44923.7771.667解读树删除需要对整棵子树递归回收进程数增加导致同一棵树的删除路径争用加剧64 进程时仅剩个位数 ops/s。该数据提示面向大量树形目录删除的负载应控制并发进程数并合理划分目录树。解读与延伸如何复现同等级别的元数据性能1. 卷参数按推荐值配置依据 环境准备测试卷的关键参数推荐值如下默认值与推荐值差异巨大直接决定元数据吞吐上限参数默认值推荐值说明Capacity10 GB300,000,000 GB容量测试时未设配额Data Replica Number3500数据副本数配合分区扩容Meta Replica Number33元数据副本数Raft 组大小Data Partition Size120 GB120 GB数据分区理论上限不预分配空间Data Partition Count101500数据分区数量扩展至 500 副本Meta Partition Count310元数据分区数量决定元数据并行度FollowerReadFalseFalse是否开启 FollowerReadCross ZoneFalseFalse是否跨可用区创建卷的命令mp-count参数定义见 cli/cmd/const.go 的CliFlagMetaPartitionCount./cfs-cli volume create test-vol {owner} --capacity300000000 --mp-count10执行后会交互式确认卷配置capacity 300000000 G、mpCount 10、size 120 G、followerRead false 等确认后输出Create volume success.。2. 扩展数据分区数量将数据分区扩展至 500 个副本规模通过 Master 的 HTTP 接口批量创建分区接口实现见 api_service.go 的createDataPartition对应 Cluster 层 cluster.go 的createDataPartition每次创建会为新分区分配 raft 组并指定目标主机curl -v http://10.196.59.198:17010/dataPartition/create?count32nametest-vol其中17010为 Master 的 HTTP 服务端口count32表示本次批量新增 32 个数据分区可多次调用直至分区数量满足要求。3. 挂载卷并运行 mdtest将卷挂载到/mnt/cfs/mdtestCubeFS 客户端挂载见 client/fuse.go然后按上文脚本执行。若追求顺序写与高并发场景的更大吞吐可参考 FUSE 参数优化 调整内核FUSE_MAX_PAGES_PER_REQ如 256与FUSE_DEFAULT_MAX_BACKGROUND如 32再重新编译并modprobe fuse加载。4. 结合 IO 性能交叉评估元数据性能与 IO 性能应联合评估对应 IO 性能评估 中 fio 的实测数据顺序读 8 客户端 × 64 进程可达约 17.5 GB/s 带宽随机读 IOPS 可达约 76 万可判断在混合负载下元数据面与数据面是否存在资源争用从而确定 Metanode 与 Datanode 的混合部署比例。结论与注意事项扩展能力平铺的目录/文件创建删除类操作CubeFS 元数据吞吐可随客户端与进程数扩展至数万至十余万 ops/s8 客户端 × 64 进程且单客户端 64 进程时已达 2 万 ops/s 量级读操作为王目录 stat 类纯读操作可达百万级 ops/s凸显 Metanode 内存索引与 FollowerRead 的价值树形操作为短板Tree Creation/Removal 属递归结构操作高并发下吞吐不升反降规划目录结构时应避免过深、过宽的目录树并发操作环境约束以上数据来自 v3.3.1 版本的特定硬件环境80 核 / SSD / 50Gb/s 网络不同硬件与版本含内核 FUSE 参数下结果会有差异建议在自身环境按相同方法复测后再作为容量规划依据。赞分享存储分布式文件系统对象存储云原生【免费下载链接】cubefscloud-native distributed storage项目地址https://gitcode.com/gh_mirrors/cu/cubefs点击查看免费下载相关推荐CubeFS 元数据性能评估基于 mdtest 的目录与文件操作基准测试实战指南CubeFS 元数据性能评估基于 mdtest 的目录与文件操作基准测试实战指南 本指南以 CubeFS 官方在 v3.3.1 集群环境下使用 mdtest存储分布式文件系统对象存储云原生大麦自动抢票实战5 分钟跑通脚本开票前 10 分钟做什么大麦自动抢票实战5 分钟跑通脚本开票前 10 分钟做什么 这是一套 Python 写的大麦自动抢票系统Web 端用 Selenium 驱动 ChromeGUI 自动化RPACubeFS 小文件性能评估基于 mdtest 的基准测试方法与结果解读CubeFS 小文件性能评估基于 mdtest 的基准测试方法与结果解读 导读 小文件场景是分布式文件系统最苛刻的考验之一单文件数据量小、元数据操作占比极高存储分布式文件系统对象存储云原生上一篇如何高效实现抖音内容批量下载与去水印保存下一篇5分钟掌握抖音内容批量下载无水印保存你喜欢的每一刻创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考