闯关：CephFS 突然卡住，客户端全在等
带宽正常、OSD 全绿，但 ls 一个目录要等半分钟。问题在元数据层。
学完这节你能做到
- 区分数据面故障与元数据面故障
- 读懂 MDS 的 slow request 与 cap 相关告警
- 定位到具体是哪个客户端在制造压力
场景
周四下午 14:20，AI 平台组在群里说：
CephFS 是不是有问题？我们的训练任务卡在读数据那一步半小时了，
ls一个目录要等三十秒。但是同事拷一个大文件又很快。
这句话里藏着最关键的线索：大文件很快、ls 很慢。上一阶段学过，这两件事走的是完全不同的路径。
ls/stat/open/create→ 元数据路径 → MDS + metadata pool- 读写文件内容 → 数据路径 → 客户端直连 OSD + data pool
数据面正常而元数据面慢，说明问题在 MDS 或 metadata pool，不用去看 OSD 的带宽。
- 1.先确认集群整体状态与告警类型
- 2.展开告警，看清 MDS 到底在抱怨什么
- 3.看 MDS 的请求速率与缓存规模
- 4.确认 MDS 缓存上限的配置值
- 5.找出制造压力的客户端
- 6.到客户端上确认它在做什么
模拟终端：CephFS 元数据操作变慢，数据读写正常。 输入 goals 看目标，hint 要提示。
复盘
结论：gpu-node-07 和 gpu-node-08 上的训练任务用 48 个 worker 并发遍历一个含 128 万文件的单目录，产生约 9000 req/s 的元数据请求。MDS 的 mds_cache_memory_limit 仍是默认 4GB，缓存被打满（inode 数顶在 4096k），导致大量请求需要回 metadata pool 读取，进而出现 slow request 与日志段积压。
依据：
- 数据面完全正常（OSD 全 up、PG 全 clean、读带宽 1.8 GiB/s）→ 排除数据路径
MDS_SLOW_REQUEST+MDS_TRIM同时出现 → MDS 处理能力不足DNS/INOS恰好顶在 4096k → 缓存达到上限client ls显示两个客户端占 92% 的 cap → 压力高度集中- 客户端侧确认：单目录 128 万文件 × 48 并发 worker
处置分三个层次（这一点很重要——存储侧只能缓解，治本要靠应用侧）：
# ── 立即缓解（存储侧）──
# 1. 调大 MDS 缓存（注意先确认节点内存余量）
ceph config set mds mds_cache_memory_limit 34359738368 # 32GB
# 2. 确认元数据池在 SSD 上
ceph osd crush rule create-replicated ssd-rule default host ssd
ceph osd pool set cephfs.prod.meta crush_rule ssd-rule
# ── 中期改善（存储侧）──
# 3. 开多活 MDS，并把不同业务目录钉到不同 rank
ceph fs set prod max_mds 2
ceph orch apply mds prod --placement="4"
setfattr -n ceph.dir.pin -v 1 /mnt/cephfs/datasets
# ── 治本（应用侧 + 架构）──
# 4. 数据集打包成大文件（webdataset / tar shards / LMDB），
# 把数千万次元数据操作降到几千次
# 5. 单目录拆分成多级目录，避免 128 万文件挤在一个目录
# 6. 长期看：AI 训练场景本就不适合 CephFS，评估 GPFS / Weka / VastData把缓存从 4GB 调到 32GB，能撑住 8 倍的元数据量。但训练集群一扩容、数据集一变大，同样的问题会再次出现——而且缓存上限受限于单台机器的内存，无法通过加节点线性扩展。
这就是 storplan 选型表里那句「CephFS 元数据缓存受节点内存限制，不足时性能锐减，不建议应用于 AI 场景」的实际含义。这一关的价值不只是学会排查，更是理解那句结论是怎么来的。
不要只说「是你们客户端的问题」。有效的沟通是：
- 给出事实：你们两台机器占了 92% 的元数据请求，单目录 128 万文件
- 给出已做的缓解：MDS 缓存已从 4GB 调到 32GB，预计能改善 X
- 给出对方能做的：把数据集打包成 tar shards，元数据操作能降两个数量级
- 给出长期建议：这个规模的训练数据集，建议评估专门的并行文件系统
只做第 1 步会变成扯皮，四步都做才是解决问题。
用户反馈「ls 很慢但拷大文件很快」。这个现象最先能排除什么？
ceph fs status 显示 DNS 和 INOS 都恰好是 4096k。这说明什么？
定位到两个客户端占了 92% 的 cap 之后，下面哪些是合理的后续动作？（多选）
这一关的落点
- 元数据慢而数据快 → 立刻锁定 MDS 与 metadata pool，不用查 OSD
MDS_SLOW_REQUEST与MDS_TRIM常同时出现，都是 MDS 过载的信号- 缓存条目数顶在整数上 =
mds_cache_memory_limit卡住了 ceph tell mds.<name> client ls按num_caps排序，能直接找出压力源- 处置要分三层：存储侧缓解、应用侧治本、架构层选型
- 海量小文件 + CephFS 是结构性错配，调参只能延后问题
延伸资料
- ·k8s-in-action
storage/cephadm/3-deploy-cephfs.md