一个真实的生产案例：CPU 周期性飙升，却找不到任何高 CPU 进程。
故事的开始：一个让人抓狂的 CPU 抖动问题
深夜 2 点，小王被监控告警惊醒。
公司核心业务服务器的 CPU 出现了诡异的"抖动"——每隔几秒就会飙到 80%，然后又落回 20%，如此反复。
%Cpu(s): 2.5 us, 45.0 sy, 0.0 ni, 52.5 id... <- 突然飙升 %Cpu(s): 3.0 us, 12.0 sy, 0.0 ni, 85.0 id... <- 又落回来 %Cpu(s): 2.0 us, 55.0 sy, 0.0 ni, 43.0 id... <- 又飙了
奇怪的是：
top看不到任何高 CPU 的进程。sys很高，但user很低。- 业务日志没有任何异常。
"到底是谁在搞鬼？" 小王盯着屏幕一脸茫然。
传统排查：大海捞针
按照常规思路，小王开始了漫长的排查：
# 看进程？没有异常 top -c # 看系统调用？太多了看不过来 strace -p xxx # 看内核日志？一切正常 dmesg
2 个小时过去了，问题依然没有头绪。
如果你也遇到过类似的场景，一定能理解那种"明明有问题却找不到原因"的抓狂感。
SysOM Agent 登场：3 分钟定位根因
第二天，小王决定试试 SysOM Agent。
阿里云操作系统控制台（https://alinux.console.aliyun.com）是一站式操作系统运维管理平台，提供了内存、I/O、网络、内核崩溃等强大的系统诊断能力，SysOM是操作系统控制台的运维组件。SysOM Agent 是SysOM 的智能助手，接入了 SysOM MCP 的诊断能力。点击右上角的图标即可和 SysOM Agent 对话。
小王只输入了一句话：
“我的实例 i-12345 的 CPU 使用率出现周期性抖动，sys 很高”
接下来发生的事情，让他大开眼界——
第一步：火焰图锁定热点函数
SysOM Agent 自动调用了 CPU Profiling 能力，采集了抖动时间段的火焰图。
结果一目了然：
native_queued_spin_lock_slowpath <- 占用 40%+ CPU！ _raw_spin_lock lockref_get_not_dead legitimize_path try_to_unlazy_next walk_component lookup_fast
Agent 诊断结论：大量 CPU 时间消耗在 native_queued_spin_lock_slowpath ——这是内核自旋锁的慢路径。
第二步：追溯问题源头
Agent 进一步分析调用栈：
lookup_fast → try_to_unlazy_next → __legitimize_path
这条链路说明：VFS 路径解析时，RCU 快路径失败，被迫走到了需要获取锁的慢路径。
但为什么会这样？
第三步：抓到“真凶”
Agent 进一步分析调用栈：Agent通过火焰图深入分析，确认 CPU 抖动的根因为 Negative Dentry 堆积引发的 VFS 锁竞争风暴。
- 诱因： 业务逻辑中存在高频访问不存在文件的行为，导致内核 Dentry Cache 中堆积了海量的 Negative Dentry。
- 触发： 当系统触发内存回收或 Dentry 缓存达到阈值时，内核回收进程会调用 shrink_dentry_list 尝试销毁这些条目，这会频繁修改父目录的序列计数器（d_seq）并持有 dentry 的自旋锁（d_lock）。
- 冲突： 此时，业务进程的高频路径解析（RCU Path Walk）会因为检测到 dentry 状态变更或序列号不一致而导致 RCU 模式失效。
- 恶化： 大量并发线程被迫从 RCU 模式切换到 Refcount 模式（Unlazy 流程），并集体尝试调用 legitimize_path 来获取 dentry 的引用。该过程需要频繁竞争 d_lock 自旋锁，最终在 lockref_get_not_dead 处爆发严重的锁竞争。
- 现象： 这种高密度的锁竞争将 CPU 拖入 native_queued_spin_lock_slowpath 的长时自旋中，表现为系统负载和内核态 CPU 使用率的剧烈抖动。
完整诊断报告详见文末的附录1。
Negative dentry 导致的 CPU 抖动是一个非常隐蔽的问题：
| 特征 | 说明 |
| 难发现 | top/ps 看不到高 CPU 进程 |
| 难定位 | 需要火焰图 + 内核知识 |
| 易忽视 | 抖动可能被误认为"正常波动" |
| 影响大 | 会导致业务响应延迟不稳定 |
SysOM Agent 已经帮助多家企业定位过类似问题，平均诊断时间从 4 小时缩短到 5 分钟。
为什么 SySOM Agent 能做到？
1、多维度数据融合
不是简单地看 top/vmstat，而是：
- 火焰图：精准定位内核热点。
- 调用栈：理解代码执行路径。
- bpftrace：动态追踪内核行为。
2、专家级诊断逻辑
Agent 内置了资深 SRE 的诊断思路：
- 看到
native_queued_spin_lock_slowpath→ 联想到锁竞争。 - 看到
lookup_fast降级 → 理解 VFS 缓存机制。 - 看到 dentry 相关 → 检查文件系统访问模式。
3、一句话交互
不需要你记住复杂的命令，只需描述问题现象：
❌ 传统方式: perf record -ag -- sleep 20 && perf report && bpftrace ... ✅ SysOM Agent: "我的机器CPU sys 很高，有周期性抖动"
立即体验 SysOM Agent
如果你的系统也有类似的 CPU 抖动问题，不妨让 SysOM Agent 试试，让专家级诊断能力触手可及：
1、登录 SysOM 控制台（https://alinux.console.aliyun.com），纳管节点，等待问题复现。
2、打开智能助手，输入问题描述，自动诊断结果。
相关文档：
如何纳管节点：https://help.aliyun.com/zh/alinux/component-management
进程热点追踪：https://help.aliyun.com/zh/alinux/process-hotspot-tracking
如果你有自己的 Agent，也可以试试接入SysOM MCP（https://github.com/alibaba/sysom_mcp），SysOM MCP 脱胎于阿里云操作系统控制台，把复杂的运维操作转化为 AI 可直接调用的标准工具，让 AI Agent 能像专业工程师一样“动手”诊断系统问题——用户无需懂命令，只需用自然语言提问，即可获得精准的系统级分析。
SysOM MCP 支持 --stdio （本地嵌入）和 --sse （HTTP 服务）两种模式，轻松集成各类 AI 客户端。
要在支持 MCP 协议的 AI Agent 平台（如 Qwen Code）中使用 SysOM MCP，首先需将项目代码克隆到本地：
git clone https://github.com/alibaba/sysom_mcp.git cd sysom_mcp
再在配置文件中添加如下配置，就可以让 AI 助手能以自然语言驱动操作系统及运维操作。
{ "mcpServers": { "sysom_mcp": { "command": "uv", "args": ["run", "python", "sysom_main_mcp.py", "--stdio"], "env": { "ACCESS_KEY_ID": "your_access_key_id", "ACCESS_KEY_SECRET": "your_access_key_secret", "DASHSCOPE_API_KEY": "your_dashscope_api_key" }, "cwd": "<sysom mcp项目目录>", "timeout": 30000, "trust": false } } }
附录1：完整诊断报告
┌─────────────────────────────────────────────────────────┐ │ SysOM Agent 诊断报告 │ ├─────────────────────────────────────────────────────────┤ │ 问题现象: CPU sys 周期性飙升，load 抖动 │ │ │ │ 根因分析: │ │ 1. 用户进程高频访问不存在的路径 │ │ 2. 产生大量 negative dentry 并被周期性回收 │ │ 3. VFS 路径解析从 RCU-walk 降级到 REF-walk │ │ 4. dentry 自旋锁竞争导致 CPU 抖动 │ │ │ │ 解决方案: │ │ 1. 应急: sync && echo 2 > /proc/sys/vm/drop_caches │ │ 2. 修复: 检查业务代码，避免访问不存在的路径 │ │ 3. 优化: 缓存文件存在性检查结果 │ └─────────────────────────────────────────────────────────┘
附录2：什么是 Negative Dentry？
当你访问一个不存在的文件时：
ls /path/to/nonexistent_file # ls: cannot access '/path/to/nonexistent_file': No such file or directory
内核不会每次都去磁盘查找，而是会创建一个 negative dentry 来缓存"这个文件不存在"的信息。
这本来是一个优化机制，但当：
- 大量进程高频访问不存在的路径
- 同时系统又在回收 dentry 缓存
就会触发 VFS 层面的锁竞争，导致 CPU 抖动。
如何自查？
# 查看 dentry 缓存状态 cat /proc/sys/fs/dentry-state # 输出: nr_dentry nr_unused age_limit want_pages dummy dummy # 如果 nr_dentry 数值很大（数十万以上），可能存在问题
SysOM Agent —— 让复杂问题变简单
联系我们
若想使用更全面的 SysOM 功能，请登录阿里云操作系统控制台体验，地址：
https://alinux.console.aliyun.com/
您在使用操作系统控制台的过程中，有任何疑问和建议，可以搜索群号：94405014449 加入钉钉群反馈，欢迎大家扫码加入交流。
