3. 设备基础运行状态诊断
网络故障排查时，工程师往往先看接口、路由、协议，却忽略了一个更底层的事实：所有转发、协议计算、表项维护都依赖设备的CPU、内存、供电、散热和板卡这些物理与资源基础。当这些基础状态异常时，故障表现常常是"协议时通时断""转发丢包""管理口登录缓慢"这类看似软件问题的现象。本节把设备基础运行状态作为一类独立的诊断维度，讲清各资源异常如何传导为网络性能问题，以及如何用Comware命令定位。
一、CPU异常：控制平面与转发平面的资源竞争
Comware设备上CPU承担协议报文收发、路由计算、表项下发、管理访问等任务。CPU占用率持续偏高时，最直接的影响是协议报文处理延迟增大，BGP/OSPF邻居可能因Hello或Keepalive超时抖动；同时管理面响应变慢，SSH登录、SNMP采集出现超时。需要区分的是：Comware采用控制平面与转发平面分离设计，普通数据转发由ASIC完成，不消耗CPU，因此"CPU高但转发正常"是常见现象；但一旦涉及需要上送CPU的报文（如ARP、DHCP、部分ACL匹配、隧道解封装），CPU拥塞就会直接造成丢包。
排查时先用 display cpu-usage 查看整体占用与最近5秒、1分钟、5分钟平均值，再用 display cpu-usage history 观察趋势。若某任务持续占高，用 display process cpu 排序定位进程。常见高CPU来源包括：路由震荡导致大量路由计算、广播风暴或ARP攻击导致报文上送、大量Telnet/SSH暴力登录、日志输出过于频繁。定位到进程后，再结合 display logbuffer 与接口流量判断根因。
display cpu-usage
display cpu-usage history
display process cpu
display process cpu | include high
二、内存异常：表项容量与系统稳定性的边界
内存不足的表现比CPU更隐蔽。Comware将内存划分为多个区域，路由表、MAC表、ARP表、会话表都占用内存。当内存使用率超过阈值，新表项可能无法下发，表现为"路由学不到""新用户上不了网"；严重时触发内存告警甚至进程重启。排查用 display memory 查看总量、已用、空闲和最低剩余，用 display memory threshold 查看告警阈值。若某进程内存持续增长，需怀疑内存泄漏，可通过 display process memory 对比多次采集结果。
需要特别注意的是，内存"看起来够用"不等于安全。设备运行中会预留缓冲区，实际可用内存低于显示值。当空闲内存低于总内存的10%～15%时，就应视为风险状态，提前清理无用表项、优化路由聚合或扩容。
三、温度、电源、风扇：环境与供电的连锁反应
温度异常通常由风扇故障或机房空调失效引起。设备温度过高时，芯片会降频保护，转发性能下降，严重时单板自动下电。排查用 display environment 查看各温度传感器当前值与阈值，用 display fan 查看风扇状态与转速，用 display power 查看电源模块在位、供电和告警状态。
电源问题更具破坏性：单电源故障时若另一路正常，设备仍运行但失去冗余；双电源同时异常则整机掉电。风扇停转往往先表现为温度缓慢上升，再触发温度告警，因此"温度告警"和"风扇告警"要联动看。板卡状态用 display device 查看各槽位单板在位、注册和运行状态，用 display board 查看单板详细信息。板卡未注册或反复重启，会导致该板卡上的接口全部不可用，进而引发路由收敛和流量绕行。
四、排查顺序与判断依据
面对"网络变慢或抖动"的报障，建议按"先看硬件环境、再看资源占用、最后看协议与流量"的顺序推进，因为硬件类异常会同时污染上层所有指标。第一步执行 display device 和 display power，确认所有单板、电源在位且无告警；第二步执行 display fan 和 display environment，确认风扇转速正常、各温度点低于告警阈值；第三步执行 display cpu-usage 和 display memory，确认资源占用在合理区间。这三步可在1分钟内完成，却能排除大部分"看起来像协议问题"的底层故障。
判断阈值方面，可参考以下经验区间（示例值，实际以设备规格和现网基线为准）：CPU 5分钟平均持续高于70%需关注，高于90%需立即处理；内存空闲低于总容量15%需关注，低于10%需处理；温度接近告警阈值10℃以内需检查散热；风扇出现"Absent"或转速为0需立即更换；电源出现"Fault"或仅单路供电需尽快恢复冗余。板卡状态出现"Fault""Offline"或反复注册，应结合 display logbuffer 中的单板日志判断是硬件故障还是版本兼容问题。
display cpu-usage、display memory、display environment 的输出并归档。故障时与基线对比，比单纯看绝对值更容易发现异常。五、从异常到根因的闭环
基础状态诊断的价值在于把"网络慢"拆解为可验证的具体原因。例如：某汇聚交换机用户反映上网卡顿，display cpu-usage 显示CPU 5分钟平均85%，display process cpu 发现ARP任务占高，进一步 display arp | include count 发现ARP表项异常增长，最终定位为某接入区广播风暴导致大量ARP上送。处理方式是先在接入端口做风暴抑制，再清理异常ARP，CPU随即回落，业务恢复。这个链条说明：CPU高是现象，ARP上送是机制，广播风暴才是根因，而基础状态命令正是把三者串起来的工具。
同样，内存告警可能源于路由表膨胀，温度告警可能源于机房空调故障，板卡异常可能源于背板接触或版本不匹配。诊断时不要停留在"重启解决"，而应记录异常发生的时间、命令输出和关联日志，形成可复用的判断经验。只有把CPU、内存、温度、电源、风扇、板卡作为一个整体状态面来观察，才能在网络性能问题出现时快速缩小范围，避免在协议层反复无效排查。