一个真实的生产案例：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 抖动是一个非常隐蔽的问题：

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 加入钉钉群反馈。

来源  |  阿里云开发者公众号

作者  |  万瑞萍、陈诗雁