在实际的网络中，总会存在设备出现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

CPU utilization for five seconds:5%/0%; one minute: 6%; five minutes: 5%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
1 4539 89782 50 0.00% 0.00% 0.00% 0 Chunk Manager
2 1042 1533829 0 0.00% 0.00% 0.00% 0 Load Meter
3 0 1 0 0.00% 0.00% 0.00% 0 DiagCard3/-1
4 14470573 1165502 12415 0.00% 0.13% 0.16% 0 Check heaps
5 7596 212393 35 0.00% 0.00% 0.00% 0 Pool Manager
6 0 2 0 0.00% 0.00% 0.00% 0 Timers
7 0 1 0 0.00% 0.00% 0.00% 0 Image Licensing
8 0 2 0 0.00% 0.00% 0.00% 0 License Client N
9 1442263 25601 56336 0.00% 0.08% 0.02% 0 Licensing Auto U
10 0 1 0 0.00% 0.00% 0.00% 0 Crash writer
11 979720 2315501 423 0.00% 0.00% 0.00% 0 ARP Input
12 0 1 0 0.00% 0.00% 0.00% 0 CEF MIB API
<output truncated>
 
如上输出示例，在最近5秒的CPU利用率有两个百分比（5%/0%）。
5%——告知CPU在最近5秒的繁忙情况，这个是活跃的系统进程CPU利用率的总量，包括了interrupt level的百分比。
0%——体现的是在最近5秒interrupt level的百分比占用情况。interrupt百分比是CPU花在从交换机硬件接收的数据包上的，该百分比总是小于等于总的CPU利用率。
 
2、识别并判断high CPU
 
2.1 正常的high 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等命令
  • 其他事件：

　　频繁或大量的IGMP请求，CPU会处理IGMP消息；
　　大量的IP SLA监控会话，CPU会生成ICMP或者traceroute数据包；
　　SNMP轮询活动，特别是MIB walk，Cisco IOS SNMP engine执行SNMP请求；
　　大量同时发出的DHCP请求；
　　ARP广播风暴；
　　Ethernet广播风暴。

2.2 通过high CPU造成的症状

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链路所需的协议数据包时，这可能导致链路断开。

2.2.4、交换机无法响应正常的管理请求：

  • 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％的中断百分比。

 
3、判断根本原因
一个输出示例，可以通过交换机用于管理数据包的系统进程识别充斥CPU的网络数据包的类型，当CPU interrupt百分比相对较高时，输入show processes cpu sorted 5sec命令来确认最活跃的进程，输出首先会列出最为活跃的进程。
Switch# show processes cpu sorted 5sec

CPU utilization for five seconds: 64%/19%; one minute: 65%; five minutes: 70%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
186 19472027 64796535 300 35.14% 37.50% 36.05% 0 IP Input
192 24538871 82738840 296 1.11% 0.71% 0.82% 0 Spanning Tree
458 5514 492 11207 0.63% 0.15% 0.63% 2 Virtual Exec
61 3872439 169098902 22 0.63% 0.63% 0.41% 0 RedEarth Tx Mana
99 10237319 12680120 807 0.47% 0.66% 0.59% 0 hpm counter proc
131 4232087 224923936 18 0.31% 0.50% 1.74% 0 Hulc LED Process
152 2032186 7964290 255 0.31% 0.21% 0.25% 0 PI MATM Aging Pr
140 22911628 12784253 1792 0.31% 0.23% 0.26% 0 HRPC qos request
250 27807274 62859001 442 0.31% 0.34% 0.34% 0 RIP Router
 
!<Output truncated>
 
表1列出了一些常见的系统进程和相关的数据包类型。 如果列出的系统进程之一是CPU中最活跃的进程，则相应类型的网络数据包很可能充斥CPU。
 

在三层交换机上，当IP route未知时，交换机硬件将会把IP数据包发送到CPU进行IP routing，发送的数据包会在interrupt level处理，并且会导致CPU繁忙。 如果命令输出中显示的中断百分比很高，但是最活跃的进程不是上表中所示的那些，或者没有任何进程看起来足够有效证明CPU利用率，那么高CPU利用率很可能是由于被发送到CPU的数据包引起的，示例输出中显示。

Switch# show processes cpu sorted 5sec

CPU utilization for five seconds: 53%/28%; one minute: 48%; five minutes: 45%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
78 461805 220334990 2 11.82% 11.53% 10.37% 0 HLFM address lea
309 99769798 1821129 54784 5.27% 1.53% 1.39% 0 RIP Timers
192 19448090 72206697 269 1.11% 0.87% 0.81% 0 Spanning Tree
250 25992246 58973371 440 0.63% 0.27% 0.29% 0 RIP Router
99 6853074 11856895 577 0.31% 0.46% 0.44% 0 hpm counter proc
131 3184794 210112491 15 0.31% 0.13% 0.12% 0 Hulc LED Process
140 20821662 11950171 1742 0.31% 0.28% 0.26% 0 HRPC qos request
139 3166446 1498429 2113 0.15% 0.11% 0.11% 0 HQM Stack Proces
67 2809714 11642483 241 0.15% 0.03% 0.00% 0 hrpc <- response
223 449344 16515401 27 0.15% 0.03% 0.00% 0 Marvell wk-a Pow
10 0 1 0 0.00% 0.00% 0.00% 0 Crash writer
11 227226 666257 341 0.00% 0.00% 0.00% 0 ARP Input
 
!<Output truncated>
 
表2列出了CPU忙于处理被发送到CPU的数据包时最活跃的系统进程，punted packets的CPU进程和列出的进程无关。

监视CPU接收队列的数据包计数

如果交换机被特定数据包类型泛洪，则硬件会将该数据包类型放入适当的CPU队列并对其进行计数。 输入show controllers cpu-interface 命令以查看每个队列的数据包计数。

Switch # show controllers cpu-interface

ASIC Rxbiterr Rxunder Fwdctfix Txbuflos Rxbufloc Rxbufdrain
-------------------------------------------------------------------------
ASIC0 0 0 0 0 0 0
ASIC1 0 0 0 0 0 0
 
cpu-queue-frames retrieved dropped invalid hol-block stray
----------------- ---------- ---------- ---------- ---------- ----------
rpc 726325 0 0 0 0
stp 16108 0 0 0 0
ipc 56771 0 0 0 0
routing protocol 3949 0 0 0 0
L2 protocol 827 0 0 0 0
remote console 58 0 0 0 0
sw forwarding 0 0 0 0 0
host 0 0 0 0 0
broadcast 382 0 0 0 0
cbt-to-spt 0 0 0 0 0
igmp snooping 3567 0 0 0 0
icmp 11256 0 0 0 0
logging 0 0 0 0 0
rpf-fail 0 0 0 0 0
dstats 0 0 0 0 0
cpu heartbeat 322409 0 0 0 0
<output truncated>
交换机还会计算由于拥塞而丢弃的CPU-bound数据包。 每个CPU接收队列都具有最大数据包计数。 当达到接收队列最大值时，交换机硬件会丢弃发往拥塞队列的数据包。 交换机为每个队列计算丢弃的数据包。 特定CPU队列的丢弃计数增加意味着该队列的使用率很高。

输入show platform port-asic stats drop 命令以查看CPU接收队列丢弃计数并识别丢弃数据包的队列。 此命令没有show controllers cpu-interface命令那么有用，因为输出显示接收队列的数字而不是名称，并且它仅显示丢弃。 由于交换机硬件将CPU接收队列丢弃的数据包视为发送给管理程序，因此丢弃的数据包在命令输出中称为Supervisor TxQueue Drop Statistics。

 
Switch #show platform port-asic stats drop

Port-asic Port Drop Statistics - Summary
========================================
RxQueue Drop Statistics Slice0
RxQueue 0 Drop Stats Slice0: 0
RxQueue 1 Drop Stats Slice0: 0
RxQueue 2 Drop Stats Slice0: 0
RxQueue 3 Drop Stats Slice0: 0
RxQueue Drop Statistics Slice1
RxQueue 0 Drop Stats Slice1: 0
RxQueue 1 Drop Stats Slice1: 0
RxQueue 2 Drop Stats Slice1: 0
RxQueue 3 Drop Stats Slice1: 0
 
!<Output truncated>
 
Port 27 TxQueue Drop Stats: 0
 
Supervisor TxQueue Drop Statistics
Queue 0: 0
Queue 1: 0
Queue 2: 0
Queue 3: 0
Queue 4: 0
Queue 5: 0
Queue 6: 0
Queue 7: 0
Queue 8: 0
Queue 9: 0
Queue 10: 0
Queue 11: 0
Queue 12: 0
Queue 13: 0
Queue 14: 0
Queue 15: 0
 
! <Output truncated>
 
Supervisor TxQueue Drop Statistics的此输出中的队列号与show controllers cpu-interface命令输出中的队列名称的顺序相同。 例如，此输出中的队列0对应于前一输出中的rpc;。 队列15对应于cpu heartbeat，依此类推。

统计信息不会重置。 多次输入命令以查看活动队列丢弃。 命令输出还显示其他丢弃统计信息，其中一些在示例中被截断。

 
其他辅助命令：
A、您还可以使用show platform ip unicast statistics 来显示有关已发送数据包的相同信息。 发送的IP数据包计为CPUAdj，在此示例中以粗体显示。
Switch# show platform ip unicast statistics

Global Stats:
HWFwdLoc:0 HWFwdSec:0 UnRes:0 UnSup:0 NoAdj:0
EncapFail:0 CPUAdj:1344291253 Null:0 Drop:0
 
Prev Global Stats:
HWFwdLoc:0 HWFwdSec:0 UnRes:0 UnSup:0 NoAdj:0
EncapFail:0 CPUAdj:1344291253 Null:0 Drop:0
这些统计信息每2到3秒更新一次。 多次输入命令以查看CPUAdj计数的变化。 当CPUAdj计数快速递增时，许多IP数据包将被转发到CPU进行IP路由。
 
B、在第3层交换机上，硬件使用TCAM来容纳IP路由数据库。 用于第3层路由信息的TCAM空间是有限的。 当此空间已满时，Cisco IOS学习的新路由无法编程到TCAM中。 如果交换机硬件接收的IP数据包具有不在TCAM中的目标IP地址，则硬件将IP数据包发送到CPU。
Switch# show platform tcam utilization

 
CAM Utilization for ASIC# 0 Max Used
Masks/Values Masks/values
Unicast mac addresses: 6364/6364 31/31
IPv4 IGMP groups + multicast routes: 1120/1120 1/1
IPv4 unicast directly-connected routes: 6144/6144 4/4
IPv4 unicast indirectly-connected routes: 2048/2048 2047/2047
IPv4 policy based routing aces: 452/452 12/12
IPv4 qos aces: 512/512 21/21
IPv4 security aces: 964/964 30/30
 
Note: Allocation of TCAM entries per feature uses
a complex algorithm. The above information is meant
to provide an abstract view of the current TCAM utilization
 
Cisco IOS从路由协议（例如BGP，RIP，OSPF，EIGRP和IS-IS）以及静态配置的路由中学习路由。 您可以输入show platform ip unicast counts 命令，以查看有多少这些路由未正确编程到TCAM中。
Switch# show platform ip unicast counts

# of HL3U fibs 2426
# of HL3U adjs 4
# of HL3U mpaths 0
# of HL3U covering-fibs 0
# of HL3U fibs with adj failures 0
Fibs of Prefix length 0, with TCAM fails: 0
Fibs of Prefix length 1, with TCAM fails: 0
Fibs of Prefix length 2, with TCAM fails: 0
Fibs of Prefix length 3, with TCAM fails: 0
Fibs of Prefix length 4, with TCAM fails: 0
Fibs of Prefix length 5, with TCAM fails: 0
Fibs of Prefix length 6, with TCAM fails: 0
Fibs of Prefix length 7, with TCAM fails: 0
Fibs of Prefix length 8, with TCAM fails: 0
Fibs of Prefix length 9, with TCAM fails: 0
Fibs of Prefix length 10, with TCAM fails: 0
Fibs of Prefix length 11, with TCAM fails: 0
Fibs of Prefix length 12, with TCAM fails: 0
Fibs of Prefix length 13, with TCAM fails: 0
Fibs of Prefix length 14, with TCAM fails: 0
Fibs of Prefix length 15, with TCAM fails: 0
Fibs of Prefix length 16, with TCAM fails: 0
Fibs of Prefix length 17, with TCAM fails: 0
Fibs of Prefix length 18, with TCAM fails: 0
Fibs of Prefix length 19, with TCAM fails: 0
Fibs of Prefix length 20, with TCAM fails: 0
Fibs of Prefix length 21, with TCAM fails: 0
Fibs of Prefix length 22, with TCAM fails: 0
Fibs of Prefix length 23, with TCAM fails: 0
Fibs of Prefix length 24, with TCAM fails: 0
Fibs of Prefix length 25, with TCAM fails: 0
Fibs of Prefix length 26, with TCAM fails: 0
Fibs of Prefix length 27, with TCAM fails: 0
Fibs of Prefix length 28, with TCAM fails: 0
Fibs of Prefix length 29, with TCAM fails: 0
Fibs of Prefix length 30, with TCAM fails: 0
Fibs of Prefix length 31, with TCAM fails: 0
Fibs of Prefix length 32, with TCAM fails: 693
Fibs of Prefix length 33, with TCAM fails: 0
要查看每个路由协议使用的路由条目数，请输入show ip route summary  命令。
Switch# show ip route summary

IP routing table name is Default-IP-Routing-Table(0)
IP routing table maximum-paths is 32
Route Source Networks Subnets Overhead Memory (bytes)
connected 5 0 320 760
static 0 0 0 0
rip 0 2390 152960 363280
internal 1 1172
Total 6 2390 153280 365212
Switch#
 
参考：https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750/software/troubleshooting/cpu_util.html#pgfId-999591
 

关于High CPU及基本排查的更多相关文章

  1. Java进程CPU使用率高排查

    Java进程CPU使用率高排查 生产java应用,CPU使用率一直很高,经常达到100%,通过以下步骤完美解决,分享一下.1.jps 获取Java进程的PID.2.jstack pid >> ...

  2. CPU高问题排查

    双11大战开始了,这几天公司系统压测,CPU各种报警,于是找了篇关于CPU高问题排查的文章. 一个应用占用CPU很高,除了确实是计算密集型应用之外,通常原因都是出现了死循环. (友情提示:本博文章欢迎 ...

  3. Linux(2)---记录一次线上服务 CPU 100%的排查过程

    Linux(2)---记录一次线上服务 CPU 100%的排查过程 当时产生CPU飙升接近100%的原因是因为项目中的websocket时时断开又重连导致CPU飙升接近100% .如何排查的呢 是通过 ...

  4. 一次erlang 节点CPU严重波动排查

    新服务上线后观察到,CPU在10 ~ 70%间波动严重,但从每秒业务计数器看业务处理速度很平均. 接下来是排查步骤: 1. dstat -tam 大概每10s一个周期,网络流量开始变得很小,随后突然增 ...

  5. 生产环境下JAVA进程高CPU占用故障排查

    问题描述:生产环境下的某台tomcat7服务器,在刚发布时的时候一切都很正常,在运行一段时间后就出现CPU占用很高的问题,基本上是负载一天比一天高. 问题分析:1,程序属于CPU密集型,和开发沟通过, ...

  6. cpu iowait高排查的case

    在之前的常见的Java问题排查方法一文中,没有写cpu iowait时的排查方法,主要的原因是自己之前也没碰到过什么cpu iowait高的case,很不幸的是在最近一周连续碰到了两起cpu iowa ...

  7. SQL 数据库高CPU占用语句排查

    前述 最近一个项目CPU占用非常高,在IIS内设置CPU限制后系统频繁掉线,通过任务管理器发现SQLSever数据库占用CPU达到40%--70%,对于数据库本人也就处在增删查改几个操作水平层面,这次 ...

  8. JAVA程序CPU 100%问题排查

    做JAVA开发的同学一定遇到过的爆表问题,看这里解决  https://www.cnblogs.com/qcloud1001/p/9773947.html   本文由净地发表于云+社区专栏 记一次Ja ...

  9. 生产环境JAVA进程高CPU占用故障排查

    问题描述:生产环境下的某台tomcat7服务器,在刚发布时的时候一切都很正常,在运行一段时间后就出现CPU占用很高的问题,基本上是负载一天比一天高. 问题分析:1,程序属于CPU密集型,和开发沟通过, ...

  10. Java线上应用故障之CPU占用高排查与定位

    最近线上频繁报警CPU空闲不足,故紧急排查后分享给大家 1.使用top命令,获取占用CPU最高的进程号 2.查看线程号对应的进程信息 命令:ps -ef|grep 22630 3.查看进程对应的线程信 ...

随机推荐

  1. testng实现代码和数据分层

    todo: 参考: https://www.cnblogs.com/znicy/p/6534893.html

  2. Django_模型继承

    解决办法

  3. C语言数据结构——第一章 数据结构的概念

    一.数据结构的基本概念 1.1-数据结构是什么? 数据结构是计算机存储和组织数据的方式.数据结构是指相互之间存在一种或多种特定关系的数据元素的集合.一般情况下,精心选择的数据结构可以带来更高的运行或者 ...

  4. Python基础知识详解 从入门到精通（七）类与对象

    本篇主要是介绍python,内容可先看目录其他基础知识详解,欢迎查看本人的其他文章Python基础知识详解 从入门到精通(一)介绍Python基础知识详解 从入门到精通(二)基础Python基础知识详 ...

  5. Java+Selenium+Testng自动化测试学习（二）

    Java+Selenium+TestNG自动化测试框架整合 1.简化代码 封装一个定位元素的类,类型为ElementLocation package com.test; import org.open ...

  6. 【代码总结】Struts2 拦截器的处理机制

    一.什么是拦截器 拦截器是一个类,可以在Action被调用之前和之后执行代码,通常框架的很多功能都是拦截器实现的,如接收输入的参数.数据验证.文件上传等 二.工作方式 做一些Action执行前的预处理 ...

  7. 左偏树（p3377）

    题目描述 如题,一开始有N个小根堆,每个堆包含且仅包含一个数.接下来需要支持两种操作: 操作1: 1 x y 将第x个数和第y个数所在的小根堆合并(若第x或第y个数已经被删除或第x和第y个数在用一个堆 ...

  8. 使用SQL命令行更改数据库字段类型

    ALTER TABLE 表名 MODIFY COLUMN 字段名 数据类型 添加列 ALTER TABLE students ADD COLUMN address VARCHAR(100) DEFAU ...

  9. .net C# Chart控件的简单使用

    1.拖控件Chart 到界面 2. 清除默认的序列  chart1.Series.Clear();   3.生成一个序列,并添加到chart1中,序列可添加多个  Series s1 = new Se ...

  10. 05hive函数

    一. 系统内置函数 1)查看系统自带的函数 hive> show functions; 2)显示自带的函数的用法 hive> desc function upper; 3)详细显示自带的函 ...