AP CPU 为什么偏高
AP 的 CPU 承担管理面与部分数据面工作：注册与配置下发、管理帧收发、日志上报、封装解封装。CPU 持续偏高通常不是硬件故障，而是被某类流量或任务压住了。定位的关键是拿曲线与事件对齐，而不是看某一刻的读数，因为无线负载本身就具有强烈的时段性。
基本信息
| 常见来源 | 广播与组播洪泛、大量扫描探测帧、二层环路 |
|---|---|
| 管理面 | 频繁上下线注册、日志风暴、远程抓包未停止 |
| 硬件因素 | 老旧单频 AP 在高密场景下管理面吃力 |
| 观察方式 | 控制器查看 AP CPU 历史曲线与关联事件 |
| 核对方法 | 曲线与广播速率、客户端数、任务窗口逐项对齐 |
典型使用场景
- 用户投诉上网慢：需要确认是否为 AP 自身资源吃紧
- 热力图与监控断更：AP 上报异常时先看 CPU
- 新业务上线后异常：判断是否由新增流量类型引起
- 大范围同时卡顿：排查广播域与组播配置问题
- 排障收尾：确认抓包与诊断任务已停止释放资源
- 老旧设备评估：作为更换与扩容的判断依据
排查步骤
排查步骤
# 在控制器导出 AP 的 CPU 历史曲线，标出高峰时段
# 对照同时段的广播与组播速率、客户端数、重传率
# 检查是否有遗留的远程抓包或诊断任务在运行
# 核对上联端口是否有环路或异常泛洪高 CPU 常见对照
| 现象特征 | 可能原因 | 处置方向 |
|---|---|---|
| 全楼 AP 同时偏高 | 广播域过大或组播泛洪 | 收敛广播域与组播控制 |
| 单台 AP 持续偏高 | 本地环路或异常终端 | 查端口环路与终端行为 |
| 定时出现峰值 | 集中任务或日志上报 | 错峰或调整上报频率 |
| 排查期间突然升高 | 抓包与诊断任务未停 | 停止任务后复测 |
远程抓包与持续诊断是最容易被忽略的人造负载：排查结束时忘记停止，会让 AP 长期保持高 CPU，甚至在后续排查中成为新的干扰项。