关于High CPU及基本排查
Posted momentslee
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了关于High CPU及基本排查相关的知识，希望对你有一定的参考价值。
在实际的网络中，总会存在设备出现high CPU的情况，这种情况下，往往会让网络管理员比较着急，因为如果CPU持续high，可能导致设备的性能降低，严重还可能导致设备down掉。
本篇记录，主要记录一下关于high CPU的一些基本知识以及排查的方法。
1、关于high CPU
当设备启动完成后，CPU具有两个不同的功能，其一，是在ios下运行不同的进程（Process）；其二，是CPU从交换硬件中发送/接收报文进行处理。CPU同时执行这两个功能。
不管是IOS Process占用了太多的CPU还是CPU从硬件收到太多的报文，都会导致CPU high，这两者都会相互影响，例如，当CPU忙于处理收到的大量的报文，那么可能导致IOS Process无法访问CPU资源。
在正常情况下，在一些非堆叠的交换机上，CPU有一定的基线利用率，根据设备型号和类型，这个范围可以从5%到40%（设备设计上的差异），如果交换机是堆叠的，那么CPU的至少可以正常运行几个百分点利用率，堆叠中的成员数量会对整体的CPU利用率产生影响。在堆叠交换机中，CPU利用率仅仅在Master交换机上体现。另外，交换机不会报告0%的CPU利用率，因为在后台运行多个IOS进行，每秒都会执行多次。
One of the reasons that different ranges and models within those ranges will differ in the baseline utilization is differences in design. Where the earlier models of the switches with little usage of microcontrollers, the later ones do utilize these more. As more tasks are being offloaded to those microcontrollers there is an increase in communication between the CPU and the microcontrollers. The processes this will be reported under are the HULC led and the Redearth Tx an Rx processes.
通过show processes cpu sorted命令，可以看到CPU在过去5秒，1分钟，5分钟的繁忙情况，也可以看到每个系统进程对CPU占用的百分比。
Switch# show processes cpu sorted
5%——告知CPU在最近5秒的繁忙情况，这个是活跃的系统进程CPU利用率的总量，包括了interrupt level的百分比。
0%——体现的是在最近5秒interrupt level的百分比占用情况。interrupt百分比是CPU花在从交换机硬件接收的数据包上的，该百分比总是小于等于总的CPU利用率。
在一些情况下，正常的high CPU不会对网络正常影响，我们可以通过show processes cpu history去查看过去60秒，60分钟，以及72小时的CPU利用情况，你可以看到CPU的利用情况，以及是否存在突发情况。
在一些例子中，CPU飙升可能是一些已知的网络事件，例如执行“write memory”、“A Large L2 Network”拓扑发生改变”、“IP路由表的更新”、“其他IOS命令”等。
- A Large L2 Network”拓扑发生改变：STP的计算，实例越多，活跃的接口越多，越可能出现。
- IP路由表更新：更新的路由表越大，周期越频繁，接收更新的路由协议进程数量，存在任何route map或者filters等情况都可能导致。
- IOS命令：show tech、write memory、show-running configuration、debug等命令
- 其他事件：
大量的IP SLA监控会话，CPU会生成ICMP或者traceroute数据包；
SNMP轮询活动，特别是MIB walk，Cisco IOS SNMP engine执行SNMP请求；
大量同时发出的DHCP请求；
ARP广播风暴；
Ethernet广播风暴。
high CPU会影响系统进程正常运行，当系统进程不执行时，交换机或直接连接的网络设备会反映对网络问题，对于L2网络，可能会发生STP从新收敛，对于L3网络，路由拓扑可能发生变化。
当交换机CPU high时可能出现的已知症状：
2.2.1、STP topo change：当二层网络设备未在RP上及时收到STP BPDU时，它会将Root Switch的二层路径视为down，并且交换机会尝试查找新路径，那么STP将会重新收敛。
2.2.2、routing topo change：例如BGP路由震荡或OSPF路由震荡。
2.2.3、EtherChannel链路反弹：当EtherChannel另一端的网络设备没有收到维护EtherChannel链路所需的协议数据包时，这可能导致链路断开。
- ICMP ping 请求
- SNMP timeout
- Telnet或SSH会话很慢或不能建立
- UDLD flapping
- IP SLAs failures
- DHCP或802.1x failures
- 丢包或者延迟增加
- HSRP flapping
2.3 确定中断百分比
CPU利用率历史记录仅显示随时间变化的总CPU利用率。它不显示中断所花费的CPU时间。了解中断所花费的时间对于确定CPU利用率的原因至关重要。 CPU利用率历史记录显示CPU何时持续接收网络数据包，但未显示原因。
输入Cisco IOS设备输入show processes cpu sorted 5sec 命令以显示当前CPU利用率以及哪些IOS进程占用的CPU时间最多。正常情况下，中断百分比大于0％且小于5％。中断百分比可以在5％到10％之间。应调查超过10％的中断百分比。
在三层交换机上，当IP route未知时，交换机硬件将会把IP数据包发送到CPU进行IP routing，发送的数据包会在interrupt level处理，并且会导致CPU繁忙。 如果命令输出中显示的中断百分比很高，但是最活跃的进程不是上表中所示的那些，或者没有任何进程看起来足够有效证明CPU利用率，那么高CPU利用率很可能是由于被发送到CPU的数据包引起的，示例输出中显示。
Switch# show processes cpu sorted 5sec
监视CPU接收队列的数据包计数
如果交换机被特定数据包类型泛洪，则硬件会将该数据包类型放入适当的CPU队列并对其进行计数。 输入show controllers cpu-interface 命令以查看每个队列的数据包计数。
Switch # show controllers cpu-interface
输入show platform port-asic stats drop 命令以查看CPU接收队列丢弃计数并识别丢弃数据包的队列。 此命令没有show controllers cpu-interface命令那么有用，因为输出显示接收队列的数字而不是名称，并且它仅显示丢弃。 由于交换机硬件将CPU接收队列丢弃的数据包视为发送给管理程序，因此丢弃的数据包在命令输出中称为Supervisor TxQueue Drop Statistics。
统计信息不会重置。 多次输入命令以查看活动队列丢弃。 命令输出还显示其他丢弃统计信息，其中一些在示例中被截断。
以上是关于关于High CPU及基本排查的主要内容，如果未能解决你的问题，请参考以下文章