🔴 Inode/Dentry Slab 泄漏诊断报告 (Branch D2)

报告编号: BAIZE-RCA-20260604-SLB004 故障级别: P2 (中等) 报告时间: 2026-06-04 02:05 UTC 诊断来源: Kuafu 全分支诊断报告 (kuafu_full_test_report_20260604.md) 当前状态: 🔴 处理中

一、故障概览

置信度说明

二、根因速览

根本原因：fault_inode_stress.py 在短时间内高频执行文件创建和删除操作，导致内核 VFS 层的 dentry 和 inode_cache slab 缓存被持续填充。每次文件操作创建对应的 dentry 和 inode 对象，文件删除后这些缓存对象虽然标记为可回收，但内核回收速度跟不上分配速度，导致 SUnreclaim 不可回收 slab 持续增长至 86MB。dentry（44,478 活跃对象）和 inode_cache（7,800 活跃对象）均已达到 active_objs == num_objs 的满负荷状态。

故障因果链

fault_inode_stress.py 启动（PID 73）
    └─► for (高频循环):
        ├─► open() + write() + close()  // 创建文件
        │   └─► 内核分配 dentry (44,478 个)
        │   └─► 内核分配 inode (7,800 个)
        └─► unlink()                      // 删除文件
            └─► dentry/inode 标记为可回收
                └─► 回收速度 << 分配速度
                    └─► SUnreclaim: 87,372 → 87,752 kB 持续增长
                    └─► Slab Total: 157,504 → 158,376 kB
                        └─► 内核 slab 缓存膨胀
                        └─► 系统内存压力增大

事故时间线

三、排查过程

3.1 初始现象

• 进程信息: PID 73, python3 fault_inode_stress.py, 单线程
• 进程 RSS 正常: 10,240 kB (~10 MB)
• Slab 总量异常: 158,376 kB (~155 MB)，占系统内存 2%
• SUnreclaim 持续增长: 87,372 → 87,752 kB（在 ~18 秒内增长 ~380 kB）
• dentry 缓存满: 44,478 活跃对象，active_objs == num_objs
• inode_cache 缓存满: 7,800 活跃对象，active_objs == num_objs
• filp 缓存: 3,202 活跃 / 4,416 总对象（文件对象缓存）

3.2 假设驱动排查

假设 D2: inode_cache 泄漏 ✅ 确认根因

🧪 假设：高频文件创建/删除导致 inode 缓存活跃对象满负荷且不可回收部分持续增长

✅ 结论：dentry 和 inode_cache 均已满载（活跃对象数 == 总对象数），SUnreclaim 持续上行，确认内核 slab 缓存泄漏。

假设 D1: dentry 缓存泄漏

⚠️ 不单独排除：dentry 和 inode_cache 均满负荷且相互关联（文件操作同时创建两者），D1 和 D2 共同构成故障。

假设 D3: kmalloc-* 通用缓存泄漏

❌ 排除：kmalloc 通用缓存（kmalloc-32/96/128/512 等）活跃度正常，无异常增长。

假设 E: vmalloc 泄漏

❌ 排除：vmalloc 使用量稳定无增长。

假设 F: kmalloc 未释放

❌ 排除（有条件）：kmalloc 缓存稳定，但因 kmemleak 不可用，少量 kmalloc 泄漏无法完全排除。

3.3 排查结论与逻辑树

系统 Slab=155MB, SUnreclaim=86MB 持续增长
└─► PID 73 (fault_inode_stress.py) 高频文件创建/删除
    │
    ├─► 假设 D1: dentry 缓存泄漏
    │       └─► dentry active=44,478 == num=44,478 ✅ 满载
    │
    ├─► 假设 D2: inode_cache 泄漏 → 🎯 确认根因
    │       └─► inode_cache active=7,800 == num=7,800 ✅ 满载
    │       └─► SUnreclaim 87,372→87,752 kB ↑ 持续增长 ✅
    │
    ├─► 假设 D3: kmalloc 泄漏 → ❌ kmalloc 缓存稳定
    │
    ├─► 假设 E: vmalloc 泄漏 → ❌ VmallocUsed 37MB 稳定
    │
    └─► 假设 F: kmalloc 未释放 → ⚠️ kmemleak 不可用，但 kmalloc 活跃度正常

四、关键证据

1. 证据1 — dentry 缓存满载：slabinfo_final.txt 中 dentry 缓存 active=44,478, num=44,478，100% 利用率，所有 slab 对象均被占用。
2. 证据2 — inode_cache 满载：inode_cache 缓存 active=7,800, num=7,800，100% 利用率，无空闲对象可用。
3. 证据3 — SUnreclaim 持续增长：slab_trend.csv 显示 SUnreclaim 在 ~18 秒内从 87,372 kB 增长至 87,752 kB（+380 kB），增长速率约 21 kB/s。
4. 证据4 — dentry 主导地位：dentry 44,478 个对象远多于 inode_cache 7,800 个，符合预期（一个 inode 可对应多个 dentry，硬链接场景），dentry 为 slab 增长的主要贡献者。
5. 证据5 — 关联性确认：filp 文件对象缓存 active=3,202（占总 4,416 的 73%），与高频文件操作行为一致。进程 PID 73 本身 RSS 仅 10MB，确认 slab 增长由内核态 VFS 缓存驱动而非进程用户态内存。

五、反事实验证

六、排除的替代假设

• 假设 D3 (kmalloc 通用缓存泄漏)：排除。所有 kmalloc-* 缓存的 active/total 比例正常，无异常增长迹象。
• 假设 E (vmalloc 泄漏)：排除。VmallocUsed 约 37 MB 保持稳定，未随 Slab 增长而同步增长。
• 假设 F (kmalloc 未释放)：有条件排除。kmalloc 缓存稳定，但 kmemleak 不可用（CONFIG_DEBUG_KMEMLEAK 未启用），无法完全排除内核模块的 kmalloc 泄漏。

七、修复建议

7.1 应急处置

7.2 永久修复

# 修复前（故障代码模式 — 高频无节制的文件创建/删除）
for i in range(100000):
    path = f"/tmp/stress/file_{i}.tmp"
    with open(path, 'w') as f:
        f.write("data")
    os.unlink(path)    # 立即删除，但 dentry/inode 回收滞后

# 修复后（限制频率或批量操作）
import time
BATCH_SIZE = 100
for batch in range(0, 100000, BATCH_SIZE):
    for i in range(batch, batch + BATCH_SIZE):
        path = f"/tmp/stress/file_{i}.tmp"
        with open(path, 'w') as f:
            f.write("data")
        os.unlink(path)
    time.sleep(1)  # 给内核回收 dentry/inode 留出时间
    # 或显式触发：
    # os.system('echo 2 > /proc/sys/vm/drop_caches')

7.3 预防措施

1. 内核参数调优：调整 vm.vfs_cache_pressure 参数（默认 100），适当提高以加速 dentry/inode 回收：
   bash

   sysctl -w vm.vfs_cache_pressure=200

2. 文件操作频率控制：对于高频文件创建/删除的场景（如临时文件、日志轮转），在应用层加入速率限制或批量操作。
3. Slab 监控告警：监控 SUnreclaim 和 dentry/inode_cache 的 active_objs == num_objs 状态，设置告警阈值（SUnreclaim > 总内存 5%）。
4. 定期缓存回收：对于已知的高频文件操作场景，可考虑定时执行轻量级缓存回收（echo 2 > /proc/sys/vm/drop_caches），但需评估对性能的影响。

八、附件

• 进程基线表: process_baseline.csv (PID 73 行: VmRSS=10,240 kB)
• Slab 趋势数据: slab_trend.csv (SUnreclaim: 87,372→87,752 kB)
• 完整 Slab 信息: slabinfo_final.txt (dentry=44,478, inode_cache=7,800)
• 系统内存快照: meminfo_final.txt (Slab=158,376 kB, SUnreclaim=87,752 kB)
• Memcg 状态: cgroup_memory_stat.txt, cgroup_summary.txt
• 容器环境: memleak-test, Linux 6.6.87.2-microsoft-standard-WSL2
• Kuafu 全分支报告: kuafu_full_test_report_20260604.md (行 158-184)