执行display diagnostic-information耗时多久？

Question

执行 `display diagnostic-information` 命令耗时通常在 2 到 10 分钟之间，具体时间取决于设备型号、运行时长、配置复杂度及当前系统负载。在高端设备或长时间运行的网络节点中，由于需收集日志、内存状态、会话表项、路由表等大量信息，耗时可能更长。若设备存在高 CPU 或内存占用，命令执行可能出现延迟甚至卡顿。建议在网络业务低峰期执行，并通过 `display cpu` 和 `display memory` 预先评估系统状态，避免影响业务转发。

Answer 1

1. 命令执行机制与耗时原理分析

display diagnostic-information 是网络设备（如华为、H3C等厂商设备）中用于采集系统级诊断数据的关键命令，其输出内容涵盖设备软硬件状态的全貌。该命令在后台触发多个子模块的数据收集流程，包括但不限于：

• 系统日志（Log Buffer 和 Log File）
• CPU 使用率历史与实时负载
• 内存分配表及碎片信息
• ARP 表、MAC 地址表、路由表（IPv4/IPv6）
• 会话连接表（Session Table）、NAT 映射记录
• 接口统计信息、错误计数器
• 风扇、电源、温度传感器状态
• 当前运行配置与启动配置比对
• 进程列表及其资源占用
• SNMP、NetStream、IPFIX 等服务状态

由于上述每一项均需从内核或应用层独立读取并格式化，整体耗时呈现累积效应。

2. 影响执行时间的核心因素分解

影响因素	具体表现	典型延迟范围
设备型号	低端交换机 vs 高端核心路由器	2分钟 vs 8+分钟
运行时长	连续运行超过30天的日志堆积	+30%~50% 耗时
配置复杂度	MPLS VPN、VXLAN、策略路由等叠加配置	+40% 数据量增长
系统负载	CPU >70%，内存使用 >80%	响应延迟显著增加
会话规模	NAT设备承载10万+并发连接	session dump 占主导时间

3. 高负载场景下的性能瓶颈定位

当设备处于高 CPU 或内存压力下执行 display diagnostic-information，可能出现以下现象：

1. CLI 响应卡顿，出现“--- More ---”阻塞提示
2. Telnet/SSH 连接超时中断
3. 部分模块返回超时错误（如无法获取某线卡状态）
4. 生成的诊断文件缺失关键节段
5. 业务流量转发延迟上升，QoS 策略执行异常

根本原因在于该命令为同步阻塞操作，多数厂商未实现异步诊断任务调度机制，导致主控CPU短时间内承受巨大解析压力。

4. 最佳实践与风险规避策略

为确保诊断信息完整性且不影响现网业务，建议遵循如下流程：

system-view
  display cpu
  display memory
  display logbuffer | include level error
  display clock
  return
  <Wait for baseline stability>
  display diagnostic-information > logfile.txt

此流程通过前置检查降低意外风险，并将输出重定向至文件避免终端溢出。

5. 自动化诊断流程设计（Mermaid 流程图）

graph TD A[开始] --> B{是否为业务高峰期?} B -- 是 --> C[延后执行] B -- 否 --> D[执行 display cpu] D --> E[判断CPU是否>70%?] E -- 是 --> F[告警并终止] E -- 否 --> G[执行 display memory] G --> H[判断Memory是否>80%?] H -- 是 --> I[告警并终止] H -- 否 --> J[执行 display diagnostic-information] J --> K[保存至归档服务器] K --> L[结束]

该流程可集成至自动化运维平台，结合Zabbix、Prometheus等监控系统实现智能触发。