路由cpu负载过高检查
我们经常会遇到High CPU的问题,一般来说CPU 分进程高和中断高两种。中断高很多时候是由于实时的流量造成的,要根据网络的实际情况具体分析,原因有很多种,在此不一一列举了。进程高,不同的进程也有不同的root cause。 在比较常见的几种占用CPU资源进程中,有一种叫 IP Input。
在 IOS 中,我们把 SW process 叫做 IP Input 进程,顾名思义就是数据报文没有被硬件 switching cache 或者 CEF 处理,而是 punt 到 CPU 去做进一步的处理。对于一个数据包而言,有几种情况会被 punt 到 CPU。
在 switching cache 里没有该报文相关的条目。如该报文的目的地址是 1.1.1.1 而这个目的前缀在如接口所在的 cache 里找不到该条目,那么这个报文将上送CPU做进一步查找。
目的地址是到本机的报文。
广播报文。
IP 头里携带 option 的报文。
需要协议转换的报文。
需要加密或者压缩的报文(如果有了 CSA(Compression Service Adapter)和 ESA(Encryption Service Adapter) 则不需要上送 CPU 只是本地处理了)。
分片报文或者需要重组的报文。(MTU设置的不合理,就可能会出发这类问题)。
故障诊断步骤
步骤 1,通过 show cpu process 或者 sh processes cpu sorted | exclude 0.00 来查看是 CPU 高,CPU 资源是否是被 IP Input 或者其他资源占用了。
ln-t1a-rt05>sh processes cpu sorted | exclude 0.00
CPU utilization for five seconds: 97%/40%; one minute: 99%; five minutes: 99%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
188 112780212 404873385 278 54.14% 47.34% 48.09% 0 IP Input
452 32291128 170096816 189 1.43% 0.85% 0.60% 0 BGP Router
444 31584160 54483137 579 0.31% 0.19% 0.17% 0 SNMP ENGINE
442 7514572 54233626 138 0.15% 0.12% 0.10% 0 IP SNMP
2 239608 2221363 107 0.07% 0.06% 0.05% 0 Load Meter
332 9940 2296 4329 0.07% 0.07% 0.05% 0 Syslog Traps
433 14477844 2116934 6839 0.07% 0.13% 0.16% 0 Tag Control
321 12935848 171140132 75 0.07% 0.04% 0.05% 0 BGP I/O
259 660104 50553708 13 0.07% 0.04% 0.05% 0 TCP Timer
264 417244 1429570 291 0.07% 0.62% 0.54% 0 XDR mcast
446 265680 424691 625 0.07% 0.19% 0.22% 0 SNMP Traps
步骤 2,如果是 IP Input 进程导致的 CPU 利用率高,那么执行 show interface status 和 show interface,来查看哪些接口有较多的流量需要转发,以及这些接口是用何种转发机制, (fast switching / cef switching /processor)
sh int stat
Switching path Pkts In Chars In Pkts Out Chars Out
Processor 650856 73671257 526830 62471991
Route cache 330217560 821433561 6624091 1799996569
Distributed cache 0 0 0 0
Total 330868416 895104818 7150921 1862468560
Interface POS0/1/0 is disabled <<<<<<<<
FastEthernet1/0/0
Switching path Pkts In Chars In Pkts Out Chars Out
Processor 376139751 259046650 373525823 58361131
Route cache 212836164 1931396850 344019086 233164671
Distributed cache 0 0 0 0
Total 588975961 2190447507 717544911 291525922
Serial1/1/0
Switching path Pkts In Chars In Pkts Out Chars Out
Processor 34782 9898739 869284 85447616
Route cache 14178391 3542542743 206212532 2364427002
Distributed cache 0 0 0 0
Total 14213173 3552441482 207081816 2449874618
Commtouch-SC4-7513#
步骤 3,show ip traffic 的输出,可以告诉我们是哪类流量增长最快,之后我们再检查一下这类流量是否需要上送 CPU 做进一步处理的(参考上述第一部分)。就能得出一个大致的结论----High CPU 问题是什么流量导致的。
Commtouch-SC4-7513#sh ip traffic
IP statistics:
Rcvd: 3764825155 total, 1632039 local destination
0 format errors, 0 checksum errors, 46716 bad hop count
0 unknown protocol, 0 not a gateway
0 security failures, 0 bad options, 7772 with options
Opts: 103 end, 10 nop, 387 basic security, 0 loose source route
0 timestamp, 0 extended security, 44 record route
0 stream ID, 0 strict source route, 7282 alert, 0 cipso
0 other
Frags: 0 reassembled, 0 timeouts, 0 couldn't reassemble
4 fragmented, 0 couldn't fragment
Bcast: 103181 received, 61 sent
Mcast: 0 received, 32678 sent
Sent: 2929975 generated, 3758313272 forwarded
Drop: 54546 encapsulation failed, 0 unresolved, 0 no adjacency
589 no route, 0 unicast RPF, 0 forced drop
ICMP statistics:
Rcvd: 0 format errors, 0 checksum errors, 0 redirects, 10299
unreachable
319787 echo, 24545 echo reply, 0 mask requests, 0 mask replies,
1
quench
0 parameter, 0 timestamp, 0 info request, 0 other
0 irdp solicitations, 0 irdp advertisements
Sent: 0 redirects, 1205238 unreachable, 24671 echo, 319787 echo reply
0 mask requests, 0 mask replies, 0 quench, 0 timestamp
0 info reply, 45869 time exceeded, 0 parameter problem
0 irdp solicitations, 0 irdp advertisements
UDP statistics:
Rcvd: 390403 total, 1 checksum errors, 292907 no port
Sent: 199023 total, 5 forwarded broadcasts
TCP statistics:
Rcvd: 883671 total, 0 checksum errors, 1878 no port
Sent: 1135440 total
Probe statistics:
Rcvd: 0 address requests, 0 address replies
0 proxy name requests, 0 where-is requests, 0 other
Sent: 0 address requests, 0 address replies (0 proxy)
0 proxy name replies, 0 where-is replies
EGP statistics:
Rcvd: 0 total, 0 format errors, 0 checksum errors, 0 no listener
Sent: 0 total
IGRP statistics:
Rcvd: 0 total, 0 checksum errors
Sent: 0 total
OSPF statistics:
Rcvd: 0 total, 0 checksum errors
0 hello, 0 database desc, 0 link state req
0 link state updates, 0 link state acks
Sent: 0 total
IP-IGRP2 statistics:
Rcvd: 0 total
Sent: 0 total
PIMv2 statistics: Sent/Received
Total: 0/0, 0 checksum errors, 0 format errors
Registers: 0/0, Register Stops: 0/0, Hellos: 0/0
Join/Prunes: 0/0, Asserts: 0/0, grafts: 0/0
Bootstraps: 0/0, Candidate_RP_Advertisements: 0/0
IGMP statistics: Sent/Received
Total: 0/0, Format errors: 0/0, Checksum errors: 0/0
Host Queries: 0/0, Host Reports: 0/0, Host Leaves: 00
DVMRP: 0/0, PIM: 0/0
ARP statistics:
Rcvd: 2159586 requests, 978 replies, 0 reverse, 0 other
Sent: 8855 requests, 27586 replies (25987 proxy), 0 reverse
===========
Commtouch-SC4-7513#sh tech
当然,我们也可以通过 debug ip packet(detail) 来更直接地查看到底是什么样的报文上送到CPU触发了CPU High,但是由于此时CPU的利用率已经很高了,所以建议先执行
router(config)#no logging console
router(config)#no logging monitor
之后再执行 logging buffered,这样 Debug 的结果将被直接记录到 log buffer 里,而不会再 session 里不停的弹出。最后,show log 就可以看到具体的报文了。
现在可以开始 debug:
router#debug ip packet detail
IP packet debugging is on (detailed)
Debug最长不能超过 3 到 5 秒钟。可以使用 undebug all 命令停止:
router#undebug all
All possible debugging has been turned off
可以使用show logging 命令检查结果:
router#show logging
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
Console logging: disabled
Monitor logging: disabled
Buffer logging: level debugging, 145 messages logged
Trap logging: level informational, 61 message lines logged
Log Buffer (64000 bytes):
*Mar 3 03:43:27.320: IP: s=192.168.40.53 (Ethernet0/1), d=144.254.2.204
(Ethernet0/0), g=10.200.40.1, len 100, forward
*Mar 3 03:43:27.324: ICMP type=8, code=0
*Mar 3 03:43:27.324: IP: s=192.168.40.53 (Ethernet0/1), d=144.254.2.205
(Ethernet0/0), g=10.200.40.1, len 100, forward
*Mar 3 03:43:27.324: ICMP type=8, code=0
*Mar 3 03:43:27.328: IP: s=192.168.40.53 (Ethernet0/1), d=144.254.2.206
(Ethernet0/0), g=10.200.40.1, len 100, forward
*Mar 3 03:43:27.328: ICMP type=8, code=0
...
该log显示:
每 4ms 收到一个包
报文的源 IP 地址是 192.168.40.53
报文从 interface Ethernet0/1 进入的.
这些上送 CPU 的报文有不同的destination 地址.
这些报文时从 interface Ethernet0/0 发出去的
报文的下一跳是 10.200.40.1
报文是 ICMP requests (type=8)
在该例中,可以看到IP Input 进程中的 High CPU 是由源自 IP 地址 192.168.40.53 的 ping flood 造成的。
通过这种方式,SYN flood 可以很容易地被发现,因为在 debugging 输出中发现了 SYN flag :
*Mar 3 03:54:40.436: IP: s=192.168.40.53 (Ethernet0/1), d=144.254.2.204
(Ethernet0/0), g=10.200.40.1, len 44, forward
*Mar 3 03:54:40.440: TCP src=11004, dst=53,
seq=280872555, ack=0, win=4128 SYN
转载于:https://blog.51cto.com/wangzhenyu/1108726
路由cpu负载过高检查相关推荐
- linux 排查cpu负载过高原因
CPU负载查看方法: 使用vmstat查看系统维度的CPU负载 使用top查看进程维度的CPU负载 一.测试工具 1.使用 vmstat 查看系统纬度的 CPU 负载: 可以通过 vmstat 从系统 ...
- 利用 Arthas 精准定位 Java 应用 CPU 负载过高问题
Arthas 官方社区正在举行征文活动,参加即有奖品拿哦~点击投稿 作者 | 张云翔 最近我们线上有个应用服务器有点上头,CPU总能跑到99%,我寻思着它流量也不大啊,为啥能把自己整这么累?于是我登上 ...
- 宝塔php的opcache模块未载入,宝塔面板CPU负载过高使用opcache扩展的解决方法
宝塔Linux面板出现CPU负载过高怎么办?使用PHP opcache扩展加速PHP脚本,新手站长网来说说宝塔CPU负载高使用PHP扩展opcache的设置及解决方法: 宝塔面板CPU负载过高的解决方 ...
- JVM性能优化之CPU负载过高
本文来说下JVM性能优化之CPU负载过高的问题 文章目录 概述 程序测试 问题定位 本文小结 概述 一般性结论:一般来说,CPU占用高不高的问题,不是给定一个数值,例如90%以上就算高,以下就算正常, ...
- cpu负载过高产生的原因及排查
之前面试被问到,造成CPU load过高的原因有哪些?如何快速排查其原因? 开一贴,总结该相关知识 什么是cpu load 值 top命令中显示的load average即为最近1分钟.5分钟和15分 ...
- CPU负载过高的原因
一 系统中创建了大量的线程,这些线程并发运行,而且工作负载都很重,过多的线程同时运行就会导致CPU负载过高 二 JVM频繁的Full GC,非常耗费CPU资源 2.1 频繁Full GC的原因 内存分 ...
- 线上服务器CPU负载过高的问题解决过程
线上服务器CPU负载过高的问题解决过程 一.找到CPU占用过高进程 执行top命令,发现PID为12443的Java进程占用CPU高达350%,出现故障. 二.定位具体线程或代码 找到该进程后,接下来 ...
- 一次运维事故调查报告--cpu负载过高
题记:只要时间足够,在开发期间偷得懒,运维期间总会在某个恰当的时机有大的坑等着,不是坑到自己就是坑到后来人 : 九月份的某个深夜,被电话吵醒,运维说线上某个版本的两个服务器由于系统资源耗尽(主要是系统 ...
- cpu负载很高而使用率很低的缘故
cpu负载很高而使用率很低的缘故 可以用#hdparm -tT /dev/sda1 来测试 Timing cached reads: 4624 MB in 2.00 secon ...
最新文章
- 巴曙松:收到了Roger送的BCH,已全捐给慈善基金
- java异常分析;剖析printStackTrace和fillInStackTrace
- Qstring 和 String相互转换
- windows xp安装php7,在Windows XP下安装Apache+MySQL+PHP环境
- 按照月的第几周统计_商标评审案件审理情况月报(2020年第11期)
- 树莓派i2c python_树莓派2 python i2cPython中chr、unichr、ord字符函数之间的对比
- python使用指南(part1)--去重
- mysql 线性表_数据结构之线性表
- ubuntu下唤醒或休眠远程计算机
- hd4600黑苹果html5死机,黑苹果核显hd4400、hd4600显卡Clover引导驱动方法
- matlab 绘图 模板,【科研绘图】MATLAB可视化代码模板
- 基于ROS的机器人模型建立及3D仿真【物理/机械意义】
- echarts 大数据可视化
- 毫末追击智能驾驶1000天,对战蔚小理将现胜负手
- python 处理英文步骤
- high sierra php,關於macOS High Sierra 10.13 中,XAMPP php7 安裝memcache的問題
- 南京大学2020计算机考研分数线,南京大学2020考研复试分数线已公布
- vc++之windows api
- 如何将交叉引用参考文献批量变为上标
- 降低指定进程的CPU占用率(适合游戏多开)
热门文章
- Django的STATIC_ROOT和STATIC_URL以及STATICFILES_DIRS
- flume + kafka
- springmvc + mybatis + ehcache + redis 分布式架构
- 使用开发者工具调试jsp页面中的脚本
- android input出现一个多余文本窗口 解决办法
- NetBeans与myeclipse区别
- 另类架构师:在国企涂肥皂水、考研被调剂、在阿里跟十八罗汉当同事……
- 面试官:面对千万级、亿级流量怎么处理?
- 给 JDK 报了一个 P4 的 Bug,结果居然……
- 超好用的自带火焰图的 Java 性能分析工具 Async-profiler 了解一下