阿里云SysOM Agent三分钟定位CPU周期性抖动，通过火焰图等手段直击Negative Dentry堆积导致的VFS锁竞争，高效解决传统方法难以发现的系统问题。
原文标题：当 CPU 莫名抖动时，SysOM Agent 如何 3 分钟定位元凶？
原文作者：阿里云开发者
冷月清谈：
怜星夜思：
2、SysOM Agent使用了火焰图定位问题，但火焰图对于不熟悉内核的人来说可能比较难以理解。有没有更直观的方式来呈现CPU使用情况，或者说有没有可视化的工具可以帮助理解火焰图？
3、文章提到SysOM MCP可以集成到各种AI Agent平台，让AI像专家一样诊断系统问题。那么，如果我想开发一个类似的AI Agent，需要具备哪些方面的知识和技能？
原文内容
故事的开始：一个让人抓狂的 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
SysOM Agent 登场：3 分钟定位根因
第二天，小王决定试试 SysOM Agent。
阿里云操作系统控制台（https://alinux.console.aliyun.com）是一站式操作系统运维管理平台，提供了内存、I/O、网络、内核崩溃等强大的系统诊断能力，SysOM是操作系统控制台的运维组件。SysOM Agent 是SysOM 的智能助手，接入了 SysOM MCP 的诊断能力。点击右上角的图标即可和 SysOM Agent 对话。
第一步：火焰图锁定热点函数
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 使用率的剧烈抖动。
Negative dentry 导致的 CPU 抖动是一个非常隐蔽的问题：
|
特征
|
说明
|
|
难发现
|
top/ps 看不到高 CPU 进程 |
|
难定位
|
需要火焰图 + 内核知识 |
|
易忽视
|
抖动可能被误认为"正常波动" |
|
影响大
|
会导致业务响应延迟不稳定 |
为什么 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
SysOM MCP 支持 --stdio （本地嵌入）和 --sse （HTTP 服务）两种模式，轻松集成各类 AI 客户端。
git clone https://github.com/alibaba/sysom_mcp.git
cd sysom_mcp
{
"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
}
}
}
┌─────────────────────────────────────────────────────────┐
│ 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-
大量进程高频访问不存在的路径
-
同时系统又在回收 dentry 缓存
# 查看 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 加入钉钉群反馈。
