2023年7月23日发(作者：)

系统的软中断CPU使⽤率升⾼，我该怎么办？[TOC]上⼀期我给你讲了软中断的基本原理，我们先来简单复习下。中断是⼀种异步的事件处理机制，⽤来提⾼系统的并发处理能⼒。中断事件发⽣，会触发执⾏中断处理程序，⽽中断处理程序被分为上半部和下半部这两个部分。上半部对应硬中断，⽤来快速处理中断；下半部对应软中断，⽤来异步处理上半部未完成的⼯作。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 sysstat hping3 tcpdump。这⾥我⼜⽤到了三个新⼯具，sar、 hping3 和 tcpdump，先简单介绍⼀下：sar 是⼀个系统活动报告⼯具，既可以实时查看系统的当前活动，⼜可以配置保存和报告历史统计数据。hping3 是⼀个可以构造 TCP/IP 协议数据包的⼯具，可以对系统进⾏安全审计、防⽕墙测试等。tcpdump 是⼀个常⽤的⽹络抓包⼯具，常⽤来分析各种⽹络问题。本次案例⽤到两台虚拟机，我画了⼀张图来表⽰它们的关系。 你可以看到，其中⼀台虚拟机运⾏ Nginx ，⽤来模拟待分析的 Web 服务器；⽽另⼀台当作 Web 服务器的客户端，⽤来给 Nginx 增加压⼒请求。使⽤两台虚拟机的⽬的，是为了相互隔离，避免“交叉感染”。接下来，我们打开两个终端，分别 SSH 登录到两台机器上，并安装上⾯提到的这些⼯具。同以前的案例⼀样，下⾯的所有命令都默认以 root ⽤户运⾏，如果你是⽤普通⽤户⾝份登陆系统，请运⾏ sudo su root 命令切换到 root⽤户。操作和分析安装完成后，我们先在第⼀个终端，执⾏下⾯的命令运⾏案例，也就是⼀个最基本的 Nginx 应⽤：# 运⾏Nginx服务并对外开放80端⼝$ docker run -itd --name=nginx -p 80:80 nginx然后，在第⼆个终端，使⽤ curl 访问 Nginx 监听的端⼝，确认 Nginx 正常启动。假设 192.168.58.99 是 Nginx 所在虚拟机的 IP 地址，运⾏ curl 命令后你应该会看到下⾯这个输出界⾯：$ curl 192.168.58.99/...接着，还是在第⼆个终端，我们运⾏ hping3 命令，来模拟 Nginx 的客户端请求：# -S参数表⽰设置TCP协议的SYN（同步序列号），-p表⽰⽬的端⼝为80# -i u100表⽰每隔100微秒发送⼀个⽹络帧# 注：如果你在实践过程中现象不明显，可以尝试把100调⼩，⽐如调成10甚⾄1$ hping3 -S -p 80 -i u100 192.168.58.99现在我们再回到第⼀个终端，你应该发现了异常。是不是感觉系统响应明显变慢了，即便只是在终端中敲⼏个回车，都得很久才能得到响应？这个时候应该怎么办呢？虽然在运⾏ hping3 命令时，我就已经告诉你，这是⼀个 SYN FLOOD 攻击，你肯定也会想到从⽹络⽅⾯⼊⼿，来分析这个问题。不过，在实际的⽣产环境中，没⼈直接告诉你原因。所以，我希望你把 hping3 模拟 SYN FLOOD 这个操作暂时忘掉，然后重新从观察到的问题开始，分析系统的资源使⽤情况，逐步找出问题的根源。那么，该从什么地⽅⼊⼿呢？刚才我们发现，简单的 SHELL 命令都明显变慢了，先看看系统的整体资源使⽤情况应该是个不错的注意，⽐如执⾏下 top 看看是不是出现了 CPU 的瓶颈。我们在第⼀个终端运⾏ top 命令，看⼀下系统整体的资源使⽤情况。# top运⾏后按数字1切换到显⽰所有CPU$ toptop - 10:50:58 up 1 days, 22:10, 1 user, load average: 0.00, 0.00, 0.00Tasks: 122 total, 1 running, 71 sleeping, 0 stopped, 0 zombie%Cpu0 : 0.0 us, 0.0 sy, 0.0 ni, 96.7 id, 0.0 wa, 0.0 hi, 3.3 si, 0.0 st%Cpu1 : 0.0 us, 0.0 sy, 0.0 ni, 95.6 id, 0.0 wa, 0.0 hi, 4.4 si, 0. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 7 root 20 0 0 0 0 S 0.3 0.0 0:01.64 ksoftirqd/0 16 root 20 0 0 0 0 S 0.3 0.0 0:01.97 ksoftirqd/1 2663 root 20 0 923480 28292 13996 S 0.3 0.3 4:58.66 docker-containe 3699 root 20 0 0 0 0 I 0.3 0.0 0:00.13 kworker/u4:0 3708 root 20 0 44572 4176 3512 R 0.3 0.1 0:00.07 top 1 root 20 0 225384 9136 6724 S 0.0 0.1 0:23.25 systemd 2 root 20 0 0 0 0 S 0.0 0.0 0:00.这⾥你有没有发现异常的现象？我们从第⼀⾏开始，逐个看⼀下：平均负载全是 0，就绪队列⾥⾯只有⼀个进程（1 running）。每个 CPU 的使⽤率都挺低，最⾼的 CPU1 的使⽤率也只有 4.4%，并不算⾼。再看进程列表，CPU 使⽤率最⾼的进程也只有 0.3%，还是不⾼呀。那为什么系统的响应变慢了呢？既然每个指标的数值都不⼤，那我们就再来看看，这些指标对应的更具体的含义。毕竟，哪怕是同⼀个指标，⽤在系统的不同部位和场景上，都有可能对应着不同的性能问题。仔细看 top 的输出，两个 CPU 的使⽤率虽然分别只有 3.3% 和 4.4%，但都⽤在了软中断上；⽽从进程列表上也可以看到，CPU 使⽤率最⾼的也是软中断进程 ksoftirqd。看起来，软中断有点可疑了。根据上⼀期的内容，既然软中断可能有问题，那你先要知道，究竟是哪类软中断的问题。停下来想想，上⼀节我们⽤了什么⽅法，来判断软中断类型呢？没错，还是 proc ⽂件系统。观察 /proc/softirqs ⽂件的内容，你就能知道各种软中断类型的次数。不过，这⾥的各类软中断次数，⼜是什么时间段⾥的次数呢？它是系统运⾏以来的累积中断次数。所以我们直接查看⽂件内容，得到的只是累积中断次数，对这⾥的问题并没有直接参考意义。因为，这些中断次数的变化速率才是我们需要关注的。那什么⼯具可以观察命令输出的变化情况呢？我想你应该想起来了，在前⾯案例中⽤过的 watch 命令，就可以定期运⾏⼀个命令来查看输出；如果再加上 -d 参数，还可以⾼亮出变化的部分，从⾼亮部分我们就可以直观看出，哪些内容变化得更快。⽐如，还是在第⼀个终端，我们运⾏下⾯的命令：$ watch -d cat /proc/softirqs CPU0 CPU1 HI: 0 0 TIMER: 1083906 2368646 NET_TX: 53 9 NET_RX: 1550643 1916776 BLOCK: 0 0 IRQ_POLL: 0 0 TASKLET: 333637 3930 SCHED: 963675 2293171 HRTIMER: 0 0 RCU: 1542111 1590625通过 /proc/softirqs ⽂件内容的变化情况，你可以发现， TIMER（定时中断）、NET_RX（⽹络接收）、SCHED（内核调度）、RCU（RCU 锁）等这⼏个软中断都在不停变化。其中，NET_RX，也就是⽹络数据包接收软中断的变化速率最快。⽽其他⼏种类型的软中断，是保证 Linux 调度、时钟和临界区保护这些正常⼯作所必需的，所以它们有⼀定的变化倒是正常的。那么接下来，我们就从⽹络接收的软中断着⼿，继续分析。既然是⽹络接收的软中断，第⼀步应该就是观察系统的⽹络接收情况。这⾥你可能想起了很多⽹络⼯具，不过，我推荐今天的主⼈公⼯具 sar 。sar 可以⽤来查看系统的⽹络收发情况，还有⼀个好处是，不仅可以观察⽹络收发的吞吐量（BPS，每秒收发的字节数），还可以观察⽹络收发的 PPS，即每秒收发的⽹络帧数。我们在第⼀个终端中运⾏ sar 命令，并添加 -n DEV 参数显⽰⽹络收发的报告：# -n DEV 表⽰显⽰⽹络收发的报告，间隔1秒输出⼀组数据$ sar -n DEV 115:03:46 IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil15:03:47 eth0 12607.00 6304.00 664.86 358.11 0.00 0.00 0.00 0.0115:03:47 docker0 6302.00 12604.00 270.79 664.66 0.00 0.00 0.00 0.0015:03:47 lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.0015:03:47 veth9f6bbcd 6302.00 12604.00 356.95 664.66 0.00 0.00 0.00 0.05对于 sar 的输出界⾯，我先来简单介绍⼀下，从左往右依次是：第⼀列：表⽰报告的时间。第⼆列：IFACE 表⽰⽹卡。第三、四列：rxpck/s 和 txpck/s 分别表⽰每秒接收、发送的⽹络帧数，也就是 PPS。第五、六列：rxkB/s 和 txkB/s 分别表⽰每秒接收、发送的千字节数，也就是 BPS。后⾯的其他参数基本接近 0，显然跟今天的问题没有直接关系，你可以先忽略掉。我们具体来看输出的内容，你可以发现：对⽹卡 eth0 来说，每秒接收的⽹络帧数⽐较⼤，达到了 12607，⽽发送的⽹络帧数则⽐较⼩，只有 6304；每秒接收的千字节数只有 664 KB，⽽发送的千字节数更⼩，只有 358 KB。docker0 和 veth9f6bbcd 的数据跟 eth0 基本⼀致，只是发送和接收相反，发送的数据较⼤⽽接收的数据较⼩。这是 Linux 内部⽹桥转发导致的，你暂且不⽤深究，只要知道这是系统把 eth0 收到的包转发给 Nginx 服务即可。具体⼯作原理，我会在后⾯的⽹络部分详细介绍。从这些数据，你有没有发现什么异常的地⽅？既然怀疑是⽹络接收中断的问题，我们还是重点来看 eth0 ：接收的 PPS ⽐较⼤，达到 12607，⽽接收的 BPS 却很⼩，只有 664 KB。直观来看⽹络帧应该都是⽐较⼩的，我们稍微计算⼀下，664*1024/12607 = 54 字节，说明平均每个⽹络帧只有 54 字节，这显然是很⼩的⽹络帧，也就是我们通常所说的⼩包问题。那么，有没有办法知道这是⼀个什么样的⽹络帧，以及从哪⾥发过来的呢？使⽤ tcpdump 抓取 eth0 上的包就可以了。我们事先已经知道， Nginx 监听在 80 端⼝，它所提供的 HTTP 服务是基于 TCP 协议的，所以我们可以指定 TCP 协议和 80 端⼝精确抓包。接下来，我们在第⼀个终端中运⾏ tcpdump 命令，通过 -i eth0 选项指定⽹卡 eth0，并通过 tcp port 80 选项指定 TCP 协议的 80 端⼝：# -i eth0 只抓取eth0⽹卡，-n不解析协议名和主机名# tcp port 80表⽰只抓取tcp协议并且端⼝号为80的⽹络帧$ tcpdump -i eth0 -n tcp port 8015:11:32.678966 IP 192.168.0.2.18238 > 192.168.0.30.80: Flags [S], seq 458303614, win 512, 从 tcpdump 的输出中，你可以发现192.168.0.2.18238 > 192.168.0.30.80 ，表⽰⽹络帧从 192.168.0.2 的 18238 端⼝发送到 192.168.0.30 的 80 端⼝，也就是从运⾏ hping3 机器的 18238 端⼝发送⽹络帧，⽬的为 Nginx 所在机器的 80 端⼝。Flags [S] 则表⽰这是⼀个 SYN 包。再加上前⾯⽤ sar 发现的， PPS 超过 12000 的现象，现在我们可以确认，这就是从 192.168.0.2 这个地址发送过来的 SYN FLOOD攻击。到这⾥，我们已经做了全套的性能诊断和分析。从系统的软中断使⽤率⾼这个现象出发，通过观察 /proc/softirqs ⽂件的变化情况，判断出软中断类型是⽹络接收中断；再通过 sar 和 tcpdump ，确认这是⼀个 SYN FLOOD 问题。SYN FLOOD 问题最简单的解决⽅法，就是从交换机或者硬件防⽕墙中封掉来源 IP，这样 SYN FLOOD ⽹络帧就不会发送到服务器中。案例结束后，也不要忘了收尾，记得停⽌最开始启动的 Nginx 服务以及 hping3 命令。在第⼀个终端中，运⾏下⾯的命令就可以停⽌ Nginx 了：# 停⽌ Nginx 服务$ docker rm -f nginx⼩结软中断 CPU 使⽤率（softirq）升⾼是⼀种很常见的性能问题。虽然软中断的类型很多，但实际⽣产中，我们遇到的性能瓶颈⼤多是⽹络收发类型的软中断，特别是⽹络接收的软中断。在碰到这类问题时，你可以借⽤ sar、tcpdump 等⼯具，做进⼀步分析。有同学说在查看软中断数据时会显⽰128个核的数据，我的也是，虽然只有⼀个核，但是会显⽰128个核的信息，⽤下⾯的命令可以提取有数据的核，我的1核，所以这个命令只能显⽰1核，多核需要做下修改watch -d "/bin/cat /proc/softirqs | /usr/bin/awk 'NR == 1{printf "%13s %sn"," ",$1}; NR > 1{printf "%13s %sn",$1,$2}'"