系统性能之cpu 篇

Posted 2023-02-17

进程的不可中断状态是系统的一种保护机制，可以保证和硬件的交互过程不被意外打断。短时不可中断是正常的，长时间出于不可中断状态时，就得关注了。

1.软中断概念

现实场景： 以定外卖为例，假如定了2分外卖，一份主食，一份饮料，并且由2个外卖员来配送。在手机上下的订单，每个外卖员都能通过留的方式联系到你。这会主食送到了，配送员跟你打电话，打的时间比较长，商量下发票的事情。在此时此刻，配送饮料的外卖员也到了，但是死活打你电话提示一直占线中，试了几次打不通就走了？

是不是可以避免饮料外卖员打了2次你电话就离开？当然是可以的，一种就是外卖员可以多等会你，另一种就是在跟送主食的外卖员先不要沟通发票的事，说见了面再沟通，这样是不是送饮料外卖员就可以联系到你了。

其实系统的软中断机制也类似于这样处理。把中断处理分为两个阶段：

• 上半部用来快速处理中断，它在中断禁止模式下运行，主要处理跟硬件紧密相关的或时间敏感的工作。（硬中断，快速执行)
• 下半部用来延迟处理上半部未完成的工作，通常以内核线程的方式运行。（软中断，延迟执行）

再一个例子就是常见的网卡接受数据。 

网卡接收到数据包后，会通过硬件中断的方式，通知内核有新的数据到了。这时，内核就应该调用中断处理程序来响应它。对上半部来说，既然是快速处理，其实就是要把网卡的数据读到内存中，然后更新一下硬件寄存器的状态（表示数据已经读好了），最后再发送一个软中断信号，通知下半部做进一步的处理。而下半部被软中断信号唤醒后，需要从内存中找到网络数据，再按照网络协议栈，对数据进行逐层解析和处理，直到把它送给应用程序。

实际上，上半部会打断 CPU 正在执行的任务，然后立即执行中断处理程序。而下半部以内核线程的方式执行，并且每个 CPU 都对应一个软中断内核线程，名字为 “ksoftirqd/CPU 编号”，比如说， 0 号 CPU 对应的软中断内核线程的名字就是 ksoftirqd/0。

$ ps aux | grep softirq
root         7  0.0  0.0      0     0 ?        S    Oct10   0:01 [ksoftirqd/0]
root        16  0.0  0.0      0     0 ?        S    Oct10   0:01 [ksoftirqd/1]

2.如何查看软中断

proc 文件系统是一种内核空间和用户空间进行通信的机制，可以查看内核数据结构或者用来修动态修改内核配置。

/proc/softirqs 提供了软中断的运行情况；/proc/interrupts 提供了硬中断的运行情况。

图中可以看出系统有8个逻辑cpu软中断情况。 

• 从第一列你可以看到，软中断包括了 10 个类别，分别对应不同的工作类型。比如 NET_RX 表示网络接收中断，而 NET_TX 表示网络发送中断。
• 要注意同一种软中断在不同 CPU 上的分布情况，也就是同一行的内容。正常情况下，同一种中断在不同 CPU 上的累积次数应该差不多。​
• TASKLET 在不同 CPU 上的分布并不均匀。（最大值为181万，最小值为12万）TASKLET 是最常用的软中断实现机制，每个 TASKLET 只运行一次就会结束 ，并且只在调用它的函数所在的 CPU 上运行。比如，只在一个cpu运行导致调度不均衡；不能在多cpu运行带来的性能限制。

3.软中断案例分析

终端一启动服务

运行nginx服务并对外开放80端口
$ docker run -itd --name=nginx -p 80:80 nginx

终端二模拟nginx客户端请求

-S参数表示设置TCP协议的SYN（同步序列号），-p表示目的端口为80
-i u100表示每隔100微秒发送一个网络帧
注：如果你在实践过程中现象不明显，可以尝试把100调小，比如调成10甚至1
$ hping3 -S -p 80 -i u100 192.168.0.30

此时，在终端一执行各种命令，发现系统响应慢了，这会可以忽略这块的hping 事，就是终端一响应慢本事，该如何分析下呢？首先想到的就是top，看看系统整体资源使用情况

top运行后按数字1切换到显示所有CPU
$ top
top - 10:50:58 up 1 days, 22:10,  1 user,  load average: 0.00, 0.00, 0.00
Tasks: 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.0 st
...
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.03 kthreadd
...

好像看不出什么异常来，平均负载为0，就绪队列也就1个进运行；每个cpu使用率都不高；cpu使用率最高的进程也只有0.3%。就是两个CPU软中断的使用率分别为3.3%和4.4%，占用cpu最高的是软中断进程。软中断的问题？

分析思路，首先先分析下软中断，watch -d 可以实时看出哪些内容变化最快。 其中可以发现NET_RX(网络数据包接受软中断)变化率最快。

$ 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          
     TASKLET:     333637       3930
       SCHED:     963675    2293171
     HRTIMER:          0          0
         RCU:    1542111    1590625

接下来分析网络接受软中断。用sar工具观察网络接受情况。 指标说明:IFACE表示网卡；：rxpck/s 和 txpck/s 分别表示每秒接收、发送的网络帧数，也就是 PPS。rxkB/s 和 txkB/s 分别表示每秒接收、发送的千字节数，也就是 BPS。

-n DEV 表示显示网络收发的报告，间隔1秒输出一组数据
$ sar -n DEV 1
15:03:46        IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s   %ifutil
15:03:47         eth0  12607.00   6304.00    664.86    358.11      0.00      0.00      0.00      0.01
15:03:47      docker0   6302.00  12604.00    270.79    664.66      0.00      0.00      0.00      0.00
15:03:47           lo      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
15:03:47    veth9f6bbcd   6302.00  12604.00    356.95    664.66      0.00      0.00      0.00      0.05

看图说话：docker0 和 veth9f6bbcd 的数据跟 eth0 基本一致，只是发送和接收相反，发送的数据较大而接收的数据较小。这是 Linux 内部网桥转发导致的，系统把 eth0 收到的包转发给 Nginx 服务。

简单分析下：接收的 PPS 比较大，达到 12607，而接收的 BPS 却很小，只有 664 KB。直观来看网络帧应该都是比较小的，我们稍微计算一下，664*1024/12607 = 54 字节，说明平均每个网络帧只有 54 字节，这显然是很小的网络帧，也就是我们通常所说的小包问题。

最后，既然看出是小包问题，那能看出是什么样的网络帧吗？ 这会就想起用tcpdump抓个包瞅瞅，发现从192.168.0.2一直在本机的nginx服务，并没有建立完整的三次握手，而是重复显示的 Flags [S]，这不就是SYN FLOOD的问题嘛 。解决此类问题就是从防火墙或者是开启云主机的SYN防护。

-i eth0 只抓取eth0网卡，-n不解析协议名和主机名
tcp port 80表示只抓取tcp协议并且端口号为80的网络帧
$ tcpdump -i eth0 -n tcp port 80
15:11:32.678966 IP 192.168.0.2.18238 > 192.168.0.30.80: Flags [S], seq 458303614, win 512, length 0
...