CephFS 性能测试与可观测性分析
# CephFS 高负载性能测试与 MDS 可观测性分析框架
# 项目定位
该项目面向 CephFS 高负载元数据场景，建设了一套可复用的性能测试与 MDS 可观测性分析框架。
- 不同 MDS 数量、MDS cache 配置、目录布局、文件规模和业务模型下，CephFS 性能如何变化。
- 当吞吐下降或延迟升高时，瓶颈具体落在 MDS 处理能力、多 rank 协同成本、cache 压力、目录获取，还是后端存储介质。
- 运维应优先采取扩 MDS、调 cache、目录打散、介质优化，还是业务访问模式调整。
这项工作沉淀一套可迁移到其他分布式存储系统的高负载观测与瓶颈定位方法。
# 我的职责与技术范围
我负责实验方案设计、压测框架搭建、MDS perf dump 指标采集、数据清洗与增量计算、时序图表生成，以及基于 CephFS 内部指标进行瓶颈归因。
测试侧基于 OpenMPI 和 mdtest 构建 3 台压测机 / 3 租户并发模型，模拟多个业务租户同时访问同一 CephFS 的元数据场景。实验变量包括 active MDS 数量（覆盖 1 active MDS 与 3 active MDS 两类主配置）、MDS cache 大小（含 8 GB 等典型参数）、元数据池介质类型、文件数量级、目录层级、客户端并发度、纯元数据操作和真实小文件读写。围绕上述变量设计实验矩阵，累计覆盖 10+ 组配置组合，核心场景做 3 轮重复实验以降低单次抖动影响。单轮典型规模为 64 × 3 = 192 个并发客户端进程，文件规模从十万级逐步拉升到百万级；重压场景下单次实验配置为 64 进程 × 3 客户端 × 50000 文件/进程，总文件规模约 960 万。
观测侧以 10 秒为固定采样间隔周期采集 MDS admin socket 的 perf dump，单次采集覆盖数十项核心指标，形成可与压测阶段精确对齐的时序数据。原始数据保留累计值并记录时间戳、节点名和 MDS 实例名，分析阶段再转换为区间增量，避免采集阶段过早丢失信息，也让同一套原始数据可以反复用于不同维度的复盘和对比。
分析侧重点跟踪与元数据请求路径强相关的指标，包括 request、reply、reply_latency、forward、dir_fetch、peer_lookupino、mem_rss、inodes、caps、root_files、journal_latency、cache_hit 等。通过把 mdtest/fio 的外部吞吐/延迟结果与 MDS 内部时序指标对齐，可以定位性能拐点与瓶颈放大时刻，判断系统变慢时到底是请求处理能力不足、跨 rank 协同成本升高、cache 压力放大，还是后端池能力成为瓶颈。
# 测试与观测框架设计
这套框架的目标是让性能测试可重复、可比较、可扩展，而不是只得到某一次实验的静态结果。
压测框架统一管理测试变量和执行流程。每组实验固定压力模型、客户端并发、目录结构和文件数量级，围绕 MDS 数量、MDS cache、元数据池介质类型、文件规模、纯元数据操作、小文件读写等变量构建 10+ 组配置矩阵，核心场景执行 3 轮重复实验，降低偶然波动对结论的影响。
指标采集链路以 10 秒为固定间隔同步采集 MDS 内部 perf dump，不只记录 mdtest/fio 汇总结果。原始数据按时间戳、节点和 MDS 实例结构化保存，后续可以对累计指标做增量计算，生成不同时间窗口下的请求量、转发量、目录获取、协同开销和响应延迟变化，用于和压测阶段精确对齐、定位性能拐点。
可视化和分析侧将外部压测结果与内部指标放在同一时间轴上。这样可以把“吞吐下降”继续拆解为更具体的内部现象，例如 forward 上升说明请求频繁落到非权威 rank，dir_fetch 上升说明目录或元数据获取成本增加，peer_lookup 上升说明多 MDS 协同成本放大，reply_latency 上升说明内部路径恶化已经反馈到请求响应时间。
这套框架后续可以复用于产品性能基线、版本回归、参数调优、特性开关前后性能对比，以及上线前容量评估。只要替换实验变量，就可以观察不同软件配置、硬件介质、MDS 参数或业务模型对 CephFS 性能的影响。
# CephFS MDS 指标理解与瓶颈归因
CephFS 高负载性能问题不能只看最终 IOPS 或平均时延。真正能帮助定位问题的信号，通常藏在 MDS 内部请求路径和多 rank 协同行为里。理解这些指标的前提，是理解它们背后对应的 MDS 内部机制。
subtree 分区与 forward：CephFS 通过 subtree 分区将目录树划分给不同 active MDS，每个目录有且只有一个 authority rank。当客户端向非权威 rank 发起请求时，该 rank 必须将请求 forward 给 authority，这是 forward 计数上升的根因，而非随机负载不均。MDS balancer（由 mds_bal_mode 控制）负责动态调整 subtree 分配，但重新分配本身也会带来短暂 forward 高峰。因此，多 active MDS 的收益是有条件的：前提是目录 authority 分布合理，请求能稳定落到各自权威 rank。如果业务访问集中在少量热点目录，系统开销就会从”单 MDS 处理能力不足”转成”多 MDS 协同成本持续放大”。
MDCache 驱逐与 dir_fetch：MDS 将活跃的 inode 和 dentry 保留在内存 MDCache 中，其上限由 mds_cache_memory_limit 控制。当 cache 逼近上限时，MDS 需要驱逐冷 inode/dentry。若后续请求访问已驱逐的元数据，MDS 必须从 RADOS 元数据池重新加载，这次磁盘/网络 IO 就体现为 dir_fetch 上升。这也解释了文件规模增长后的拐点现象：文件量较小时 cache 命中率高，dir_fetch 不突出；一旦文件数量级持续增长、cache 压力触顶，dir_fetch、reply_latency、forward 会同时抬升，说明内部请求路径已开始恶化，而不只是”压力变大了”。
caps 机制与 reply_latency：caps 是 MDS 向客户端授予的元数据访问权限令牌，记录客户端可缓存的 inode 状态（读/写/独占等）。高并发场景下 caps 数量持续累积，会增加 MDS 的 session 管理开销；当 cache 压力触发 cap 驱逐时，MDS 需要向客户端发送 revoke 消息并等待确认，这个来回延迟会直接抬高 reply_latency，即便请求本身的处理逻辑并未变慢。
journal_latency 与元数据池介质：MDS 的每次元数据修改都要先写 MDLog journal（落到 RADOS 元数据池）。journal_latency 上升通常说明元数据池介质已成为瓶颈，此时继续扩 MDS 或调大 cache 的边际收益有限，应优先排查元数据池的 OSD 类型和 IO 负载。
瓶颈会随场景迁移。某些实验中瓶颈主要落在 MDS 元数据处理和多 rank 协同路径，在另一些场景下会进一步转向元数据池介质或数据池写入能力。如果只看 mdtest 汇总结果，很容易把所有问题误归因为”MDS 不够多”或”客户端并发太高”。把内部指标和实验变量一起看，才能识别真正的杠杆点，避免错误扩容或错误调参。
# 关键结论与运维决策价值
这项工作把 CephFS 性能分析从“看结果”推进到“解释结果”，再推进到“指导运维动作”。在系统压力升高时，运维不应默认先增加 active MDS，而应该先判断当前瓶颈类型。
如果 forward、peer_lookupino 明显上升，说明多 rank 协同成本正在放大，应优先检查目录 authority 分布、热点目录集中度和业务访问路径，而不是单纯继续扩 MDS。
如果文件规模增长后 reply_latency 与 cache 相关指标同步恶化，说明系统可能正在逼近 MDS cache 压力拐点，应优先评估 cache 配置、目录结构、inode/cap 压力和元数据池能力。
如果内部 MDS 指标没有明显恶化，但真实小文件读写性能下降，则需要继续排查数据池写入能力、介质性能和客户端侧行为，避免把数据面瓶颈误判为元数据瓶颈。
这些判断能够帮助运维人员在高负载或性能退化阶段快速缩小排查范围，更有针对性地选择扩容、调参、目录打散、介质优化等措施，减少问题持续时间，提升 CephFS 长期稳定运行能力。
# 项目产出与迁移价值
这项工作的直接产出是一套可复用的 CephFS 高负载测试与观测链路，而不是一份孤立的实验结果。它把压力模型、指标采集、数据处理、时序分析和瓶颈归因串成完整闭环，后续可以持续用于产品性能测试和版本演进验证。
对产品侧，这套框架可以用于建立性能基线，比较不同 MDS 数量、cache 参数、目录布局、文件规模、硬件介质和特性开关对性能的影响。它也可以用于新版本回归，验证功能改造是否引入额外元数据路径开销。
对运维侧，这套框架增强了系统可观测性。原本业务侧只能看到“慢”或“抖动”，现在可以继续下钻到 MDS 内部请求转发、目录获取、cache 压力、多 rank 协同和后端池能力等关键层面，使排障从被动猜测转为基于指标的判断。
从方法论层面，这项工作沉淀出”稳定压力模型 → 内部指标采集 → 增量时序分析 → 瓶颈归因 → 运维动作闭环”的完整链路。这套方法不依赖 CephFS 的具体实现，可以迁移到其他分布式存储系统、控制面服务和高并发系统的性能治理场景。