10 | 案例篇：系统的软中断CPU使用率升高，我该怎么办？

倪朋飞



该思维导图由 AI 生成，仅供参考

你好，我是倪朋飞。
上一期我给你讲了软中断的基本原理，我们先来简单复习下。
中断是一种异步的事件处理机制，用来提高系统的并发处理能力。中断事件发生，会触发执行中断处理程序，而中断处理程序被分为上半部和下半部这两个部分。
上半部对应硬中断，用来快速处理中断；
下半部对应软中断，用来异步处理上半部未完成的工作。
Linux 中的软中断包括网络收发、定时、调度、RCU 锁等各种类型，我们可以查看 proc 文件系统中的 /proc/softirqs  ，观察软中断的运行情况。
在 Linux 中，每个 CPU 都对应一个软中断内核线程，名字是 ksoftirqd/CPU 编号。当软中断事件的频率过高时，内核线程也会因为 CPU 使用率过高而导致软中断处理不及时，进而引发网络收发延迟、调度缓慢等性能问题。
软中断 CPU 使用率过高也是一种最常见的性能问题。今天，我就用最常见的反向代理服务器 Nginx 的案例，教你学会分析这种情况。
案例你的准备接下来的案例基于 Ubuntu 18.04，也同样适用于其他的 Linux 系统。我使用的案例环境是这样的：
机器配置：2 CPU、8 GB 内存。
预先安装 docker、sysstat、sar 、hping3、tcpdump 等工具，比如 apt-get install docker.io sysstat hping3 tcpdump。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

本文以Nginx反向代理服务器为例，深入探讨了软中断CPU使用率升高的常见性能问题及解决方法。通过模拟Nginx的客户端请求，作者引导读者从系统资源使用情况入手，逐步找出问题的根源。文章详细介绍了如何使用top命令观察CPU使用率、分析/proc/softirqs文件内容变化、利用sar命令查看网络收发情况以及使用tcpdump抓取网络包等方法。通过分析软中断类型和网络接收情况，读者能快速定位软中断CPU使用率升高的问题，并采取相应的解决措施。整体内容深入浅出，适合读者快速了解软中断CPU使用率升高问题及解决方法。文章还提供了实际案例，通过性能诊断和分析，解决了网络接收中断导致的软中断CPU使用率升高问题。最后，作者鼓励读者思考并分享自己的经验，以促进技术交流和进步。

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《Linux 性能优化实战》，新⼈⾸单¥68

立即购买

登录后留言

全部留言(112)

最新
精选

倪朋飞
置顶
统一回复一下终端卡顿的问题，这个是由于网络延迟增大（甚至是丢包）导致的。比如你可以再拿另外一台机器（也就是第三台）在 hping3 运行的前后 ping 一下案例机器，ping -c3 <ip> hping3 运行前，你可能看到最长的也不超过 1 ms： 3 packets transmitted, 3 received, 0% packet loss, time 2028ms rtt min/avg/max/mdev = 0.815/0.914/0.989/0.081 ms 而 hping3 运行时，不仅平均延迟增长到了 245 ms，而且还会有丢包的发生： 3 packets transmitted, 2 received, 33% packet loss, time 2026ms rtt min/avg/max/mdev = 240.637/245.758/250.880/5.145 ms 网络问题的排查方法在后面的文章中还会讲，这儿只是从 CPU 利用率的角度出发，你可以发现也有可能是网络导致的问题。
2018-12-12
5
61
Days
软终端不高导致系统卡顿，我的理解是这样的，其实不是系统卡顿，而是由于老师用的ssh远程登录，在这期间hping3大量发包，导致其他网络连接延迟，ssh通过网络连接，使ssh客户端感觉卡顿现象。
作者回复: 正解👍
2018-12-13
6
110
不去会死
搞运维好些年了。一些底层性能的东西，感觉自己始终是一知半解，通过这个专栏了解的更深入了，确实学到了很多。而且老师也一直在积极回复同学们的问题，相比某些专栏的老师发出来就不管的状态好太多。给老师点赞。
作者回复: 也很高兴看到大家有所收获😊
2018-12-27

41
卿卿子衿
有同学说在查看软中断数据时会显示128个核的数据，我的也是，虽然只有一个核，但是会显示128个核的信息，用下面的命令可以提取有数据的核，我的1核，所以这个命令只能显示1核，多核需要做下修改 watch -d "/bin/cat /proc/softirqs | /usr/bin/awk 'NR == 1{printf \"%13s %s\n\",\" \",\$1}; NR > 1{printf \"%13s %s\n\",\$1,\$2}'"
作者回复: 谢谢分享
2018-12-12
5
36
2xshu
老师，网络软中断明明只占了百分之四左右。为什么终端会感觉那么卡呢？不是很理解这点呢
作者回复: 参考置顶回复
2018-12-12

13
我来也
[D10打卡] "hping3 -S -p 80 -i u100 192.168.0.30" 这里的u100改为了1 也没觉得终端卡,top的软中断%si倒是从4%上升了不少,吃满了一个cpu. 可能是我直接在宿主机上开终端的原因,本身两个虚拟机都在这个宿主机上,都是走的本地网络. 本地网卡可能还处理的过来. ----------- 在工作中,倒是没有遇到小包导致的性能问题. 也许是用户数太少,流量不够.[才二三十兆带宽], 也许是之前发生了,自己并不知道. 在工作中遇到的软中间导致的性能问题就是上期说的usleep(1)了. ----------- 本期又学到新东西了: 1.sar 原来可以这么方便的看各网卡流量,甚至是网络帧数. 到目前为止,我都是用的最原始的方法:在网上找的一个脚本,分析ifconfig中的数据,来统计某个网卡的流量.一来需要指定某个网卡(默认eth0),二来显示的数据不太准确且不友好(sleep 1做差值). 2.nping3 居然可以用来模拟SYN FLOOD. (不要用来做坏事哦) 3.tcpdump 之前有所耳闻. 用的不多. 平常有解包需求,都是在windows下用wireshark,毕竟是图形界面. ----------- 有同学说"仅凭tcpdump发现一个syn包就断定是SYN FLOOD，感觉有些草断" 我是这样认为的: 你tcpdump 截取一段时间的日志, 除去正常的流量, 着重分析异常的,再根据ip来统计出现的次数, 还是可以合理推理出来老师结论的. 毕竟平常不会有哪个ip每秒产生这么多的syn,且持续这么长时间.
作者回复: 👍 最后一个问题其实前面已经看到PPS了
2018-12-12
2
9
黄海峰
这真是非常干货和务实的一个专栏，这么便宜，太值了。。。
作者回复: 😊
2018-12-12

7
Vicky🐣🐣🐣
1. 网络收发软中断过多导致命令行比较卡，是因为键盘敲击命令行属于硬中断，内核也需要去处理的原因吗？ 2. 观察/proc/softirqs，发现变化的值是TIMER、NET_RX、BLOCK、RCU，奇怪的是SCHED一直为0，求老师解答
作者回复: 我们是SSH登陆的机器，还是走网络而不是键盘中断😓
2018-12-12
2
6
xfan
ssh的tty其实也是通过网络传输的，既然是经过网卡，当然会卡，这就是攻击所带来的结果
作者回复: 对的
2018-12-12

5
男人十八一枝花
cat /proc/softirqs时我有4个cpu，可用 watch -d "/bin/cat /proc/softirqs | /usr/bin/awk 'NR == 1{printf \"%-15s %-15s %-15s %-15s %-15s\n\",\" \",\$1,\$2,\$3,\$4}; NR > 1{printf \"%-15s %-15s %-15s %-15s %-15s\n\",\$1,\$2,\$3,\$4,\$5}'" 查看
作者回复: 谢谢分享👍 不懂awk的赶紧去学习😊
2018-12-17
4
4

收起评论