如何理解cpu中断
2019-10-31 本文已影响0人
五月的约修亚
软中断
中断是系统响应硬件设备请求的一种机制，它会打断进程的正常调度和执行，然后调用内核中的中断处理程序来响应设备的请求。中断分为上半部和下半部
- 上半部用来快速处理中断（硬中断），它在中断禁止模式下运行（不响应其他中断），主要处理跟硬件密切相关或时间敏感的工作，快速处理防止长时间阻断其他中断
- 下半部用来延迟处理上半部未完成的工作，通常以内核线程的方式运行
比如网络请求
- 上半部是把网卡的数据读到内存中，然后更新一下硬件寄存器的状态（表示数据已经读好了）最后再发送一个软中断信号，通知下半部做进一步的处理。
- 下半部是被中断信号唤醒后，需要从内存中找到网络数据，再按照网络协议，对数据进行逐层解析和处理，知道把它送给应用程序
注意软中断不止包含硬件设备中断处理程序的下半部，一些内核自定义的时间也属于软中断，比如定时、调度、RCU锁等。
查看软中断和内核线程
- /proc/softirq 提供了10种类型的软中断次数
- /proc/interrupts 提供了硬终端的运行情况
案例
准备
通过hping3模拟大量网络小包，是目的机器频繁发生中断
# -S 参数表示设置 TCP 协议的 SYN（同步序列号），-p 表示目的端口为 80
# -i u100 表示每隔 100 微秒发送一个网络帧
# 注：如果你在实践过程中现象不明显，可以尝试把 100 调小，比如调成 10 甚至 1
$ hping3 -S -p 80 -i u100 192.168.0.30
排查
通过hping3模拟SYN FLOOD攻击后，ssh到目的机器发现响应非常缓慢
- 先通过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
...
各项指标看起来都没什么压力，但是cpu占用都在软中断上（si指标）
- 查看软中断的变化
$ 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
可以看到TIMER（定时中断）、NET_RX（网络接收）、SCHED（内核调度）、RCU（RCU 锁）等这几个软中断都在不停变化，但是NET_RX变化最快
- 通过sar命令观察网络收发情况
# -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
可以看到eth0接受的pps（rxpck/s 12607）较大，但是BPS（rxkB/s 664.86 ）却很小，计算一下每个包只有664*1024/12607=54字节，说明平均每个网络帧只有54字节，也就是我们通常说的小包问题。
- 查找小包是从哪里发过来的
使用 tcpdump 抓取 eth0 上的包就可以了。我们事先已经知道， Nginx 监听在 80 端口，它所提供的 HTTP 服务是基于 TCP 协议的，所以我们可以指定 TCP协议和 80 端口精确抓包。
# -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
...
从结果可以发现，网络帧是从192.168.0.2.18238发从到我们机器上，Flags[S]表示这是一个SYN包，再加上前面用sar发现的，PPS超过12000的现象，可以确认是这台机器发过来的SYN FLOOD攻击。最简单的解决方法就是从交换机或防火墙中封掉这个IP，这样SYN FLOOD网络帧就不会发送到服务器中
