ACG1000-AK240 cpu占用 一直 100%

联系售前确认下设备支持的并发人数

排除下性能问题

没有过保，直接打400，找售后。

ACG1000‑AK240 CPU0 一直 100%，CPU1 低，桥接 2000 + 终端网页慢
现象总结：透明桥接，未启用审计、控制策略；内网 ping 不丢包，网页打开慢；display cpu usage看到CPU0 持续 100%，CPU1 只有 50% 左右，负载不均衡。
一、为什么只有 CPU0 跑满、CPU1 空闲？
ACG1000‑AK 平台硬件调度机制：
所有上送到设备本机 CPU 的报文（DNS‑proxy、ARP、ND、各种协议报文、目的是设备自身 IP 的报文）全部交给 CPU0 处理；
纯二层桥接透传流量理论上会分配到各个数据核；但是大量 ARP、广播、DNS 代理、非监听端口报文会全部压在 CPU0；
CPU1 是数据转发核，只处理透传数据流；CPU0 是控制核，协议报文风暴会直接把 CPU0 打满，CPU1 负载上不去；
后果：二层转发 ping 报文走数据核不丢包，但是 HTTP 网页的 DNS、TCP 协议交互报文需要 CPU0 处理，CPU0 占满就会网页打开极慢。
⚠️不是整机平均 CPU 高就代表没事；只要 CPU0 单核 100% 就会业务卡顿。
二、如何看哪些进程占用 CPU？
普通用户视图只能看整体 CPU，看不到单进程。
进入probe诊断视图查看进程级 CPU 占用（需要 network‑admin 权限）
plaintext
system‑view
probe
display cpu‑usage summary
display cpu‑usage control‑plane
display cpu‑usage data‑plane
#查看连接统计，看大量目的为本机IP报文
display ip connection statistics dest‑ip any
重点看：control‑plane（控制平面，跑在 CPU0）占用率。
如果 probe 视图看到软中断 / 协议栈处理占绝大多数，不是业务进程，说明是报文风暴冲击 CPU0。
三、现场排查执行顺序（按优先级操作）
1）查看连接统计，确认是否大量报文上送 CPU0
plaintext
display ip connection statistics dest‑ip any
看是否大量目的 IP 指向 ACG 接口 IP 的报文。
开启非监听端口丢弃，减少无效报文冲击 CPU0（桥接场景常用优化）
plaintext
system‑view
local unlistened drop enable
save
作用：所有访问设备不存在端口的报文直接丢弃，不再上送 CPU 处理，降低 CPU0 压力。
2）检查是否开启 DNS‑proxy
即使桥接模式，如果开启 DNS 代理，所有 DNS 报文全部上送 CPU0 处理，2000 终端会把 CPU0 打满。
plaintext
display dns‑proxy status
#如果开启，不需要就关闭
undo dns‑proxy enable
3）查看当前实际流量，确认是否达到设备性能上限
plaintext
display statistics device‑traffic seconds 10
对比 AK240 规格：AK240 建议实际带机上限约 1200‑1500 终端，现场2000 + 终端已经超过该型号推荐带机规模。
即使不开审计策略，海量 ARP、广播、会话新建，协议报文依旧消耗控制核 CPU。
4）版本检查
确认当前软件版本，老 R66xx 版本存在桥接模式下协议报文调度 BUG，CPU0 极易打满，优先升级到官网最新稳定版本。
5）查看会话数，确认会话表压力
plaintext
display session table statistics
看当前并发会话，接近规格上限也会加重 CPU0 负担。
四、怎么判定是不是设备性能不够？
判断条件（同时满足多条说明性能不足）
已经做优化：local unlistened drop enable，关闭 DNS‑proxy，清理无用配置，升级最新版本；
终端数量 2000>AK240 官方推荐最大带机 1200‑1500；
业务高峰期 CPU0 持续 95‑100%；
网页慢、TCP 交互卡顿，ping 大包正常；
probe 视图看到控制平面 CPU 占满，无法随业务量下降。
说明：即使不开启审计 / 控制策略，仅做透明桥接，海量终端的 ARP、广播、会话新建、协议报文依旧消耗 CPU0 资源，带机量不能看最大规格标称值，要看实际并发会话与协议报文压力。
五、临时应急与长期解决方案
应急
如果硬件支持 Bypass，启用硬件 Bypass，流量绕过 ACG，业务立刻恢复，用于验证是否是 ACG 性能瓶颈。
缩小接入终端数量，分流一部分业务，观察 CPU0 是否下降。
长期方案
网络侧优化：下联交换机做 ARP 防护、抑制广播风暴，减少广播报文上送 ACG；
更换更高规格 ACG 型号（向上选 AK260/AK280）适配 2000 终端规模；
改为旁路模式：只审计不串接转发，串接转发压力交给交换机 / 防火墙。

先确认是不是性能问题，再就是升级到最新版本，看看是不是版本问题，看看接口利用率，日志这些有没有啥不对的地方