中断是一种异步的事件处理机制，可以提高系统的并发处理能力
由于中断处理程序会打断其他进程的运行，所以为了减少对正常进程运行调度的影响，中断处理程序就需要尽可能快的运行，如果中断本身要做的事情不多，那么处理起来也不会有太大问题
但如果中断要处理的事情很多，中断服务程序就有可能要运行很长时间
特别的，中断处理程序在响应中断时，还会临时关闭中断，这就会导致上一次中断处理完成之前，其他中断都不能影响，也就是说中断有可能会丢失
系统为了解决中断程序执行过长和中断丢失的问题，Linux将中断处理过程分成了两个阶段，也就是上半部和下半部
1.上半部用来快速处理中断，它在中断禁止模式下运行，主要处理跟硬件紧密相关或者时间敏感的工作
2.下半部用来延迟处理上半部未完成的工作，通常以内核线程的方式运行
以网卡接收数据为例
网卡接收到数据包后，会通过硬件中断的方式，通知内核有新的数据到了，这时内核就应该调用中断处理程序来响应它
对于上半部分来说，要把网卡的数据读到内存中，然后更新硬件寄存器的状态(表示数据已经读好了)，最后再发送一个软中断信号，通知下半部做进一步的处理
下半部被软中断信号唤醒后，需要从内存中找到网络数据，再按照网络协议栈，对数据进行逐层解析和处理，直到把它送给应用程序
上半部分直接处理硬件请求，也就是硬件中断，特点是快速执行
下半部分则是由内核处理，也就是软中断，特点是延迟执行
上半部会打断CPU正在执行的人物，然后立即执行中断处理程序，而下半部以内核线程的方式执行，并且每个CPU都对应一个软中断内核线程，名字为 ksoftireqd/CPU编号
比如0号CPU对应的软中断内核线程名字是 ksoftirqd/0
一些内核自定义的事件也属于软中断，比如内核调度和RCU锁(Read-Copy Update的缩写，是Linux内核中最常用的锁之一)
查看软中断和内核线程
/proc/softirqs 提供了软中断的运行情况
/proc/interrupts 提供了硬中断的运行情况
CPU相关的
1.使用率 top,htop,ps
2.平均负载 uptime
3.上下文切换 vmstat,dstat,pidstat -w
4.中断 vmstat /proc/interrupts,/proc/softirq
5.缓存使用率
查看软中断
cat /proc/softirqs | awk '{print $1 " " $2 " " $ 42}'
CPU0 CPU1 CPU41
HI: 0 0
TIMER: 2118204662 0
NET_TX: 2925 0
NET_RX: 29401215 0
BLOCK: 1421758 0
BLOCK_IOPOLL: 0 0
TASKLET: 120716 0
SCHED: 701921513 0
HRTIMER: 583842 0
RCU: 2414832320 0
网卡大流量导入导出数据的时候，发现是
TIMER，SCHED，RCU 在不断变化
对于硬件中断
cat /proc/interrupts | awk '{print $1 " " $2 " " $ 42}'
CPU0 CPU1
0: 294 IR-IO-APIC-edge
..
9: 0 IR-IO-APIC-fasteoi
..
73: 0 DMAR_MSI-edge
74: 121542 IR-HPET_MSI-edge
...
90: 804553 IR-PCI-MSI-edge
...
NMI: 688718 Non-maskable
LOC: 2272539373 Local
SPU: 0 Spurious
PMI: 688718 Performance
IWI: 0 IRQ
RES: 56034546 Rescheduling
CAL: 168951 Function
TLB: 373775272 TLB
TRM: 0 Thermal
THR: 0 Threshold
MCE: 0 Machine
MCP: 121529 Machine
ERR: 0
MIS: 0
LOC 每秒都在不断变化
Non-maskable 1-2秒增加一次
Rescheduling 每秒在不断变化
TLB 每秒在不断变化在查看/proc/softirqs 文件内容时需要注意
1.注意中断类型，比如软中断中NET_RX表示网络接收中断，NET_TX表示网络发送中断
2.注意同一种中断在不同CPU上的分布情况，也就是同一行的内容，在正常情况下，同一种中断在不同
CPU上的累积次数英国差不多
但TASKLET在不同的CPU上分布并不均匀，TASKLET是最常用的软中断实现机制，每个TASKLET只运行一次就会结束，并且只在调用它的函数所在的CPU上运行
所以TASKLET也会存在一些问题，比如说由于只在一个CPU上运行导致的调度不均衡，再比如不能在多个CPU上并行运行带来了性能限制
软中断是以内核线程的方式运行的，每个CPU都会对应一个软中断内核线程，这个软中断内核线程叫做
ksoftirqd/CPU编号，ps 查看如下
ps aux |grep ksoftirqd
root 3 0.0 0.0 0 0 ? S Dec06 0:02 [ksoftirqd/0]
root 11195 0.0 0.0 112660 976 pts/0 R+ 20:56 0:00 grep --color=auto ksoftirqd用hping3模拟 SYN FLOOD攻击导致的软中断上升情况
hping3 -i u1000 --syn 47.93.18.8 --destport 12345
//用 python -m 开启一个http服务top查看进程负载情况，软中断升高了，机器略卡，ksoftirqd 进程使用率也略微上升，说明软中断在影响机器
top - 22:02:55 up 13 days, 8:51, 8 users, load average: 0.00, 0.01, 0.05
Tasks: 82 total, 2 running, 80 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.7 us, 3.7 sy, 0.0 ni, 88.5 id, 0.0 wa, 0.0 hi, 6.1 si, 0.0 st
KiB Mem : 1016092 total, 94256 free, 107572 used, 814264 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 723248 avail Mem 查看 软中断情况
watch -d cat /proc/softirqs
CPU0
HI: 6
TIMER: 25174374
NET_TX: 25
NET_RX: 2309211
BLOCK: 564149
BLOCK_IOPOLL: 0
TASKLET: 57
SCHED: 0
HRTIMER: 0
RCU: 12226717
TIMER，NET_RX，RCU 这几个值都有变化，其中NET_RX变化最快，说明是网卡接收了很多数据包用sar看网络流量
//man sar 查看 DEV 结果如下
-n { keyword [,...] | ALL }
Report network statistics.
Possible keywords are DEV, EDEV, NFS, NFSD, SOCK, IP, EIP, ICMP, EICMP, TCP, ETCP, UDP, SOCK6, IP6, EIP6, ICMP6, EICMP6 and UDP6.
With the DEV keyword, statistics from the network devices are reported. The following values are displayed:
IFACE
Name of the network interface for which statistics are reported.
rxpck/s
Total number of packets received per second.
txpck/s
Total number of packets transmitted per second.
rxkB/s
Total number of kilobytes received per second.
txkB/s
Total number of kilobytes transmitted per second.
rxcmp/s
Number of compressed packets received per second (for cslip etc.).
txcmp/s
Number of compressed packets transmitted per second.
rxmcst/s
Number of multicast packets received per second.
//执行命令
sar -n DEV 1
10:08:11 PM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s
10:08:12 PM eth0 2919.19 2925.25 158.02 195.34 0.00 0.00 0.00
10:08:12 PM lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00
10:08:12 PM docker0 0.00 0.00 0.00 0.00 0.00 0.00 0.00
10:08:12 PM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s
10:08:13 PM eth0 2984.54 2990.72 161.72 211.49 0.00 0.00 0.00
10:08:13 PM lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00
10:08:13 PM docker0 0.00 0.00 0.00 0.00 0.00 0.00 0.00看第一次输出的，rxpck/s，就是每秒接收了2919个数据包
rxkb/s，是每秒收到的数据包大小为158K
158*1024/2919.0，每个数据包大概55字节，说明是大量的小包
用tcpdump 分析下对应的端口，一大堆的SYN包，可以确定就是SYN FLOOD导致的
tcpdump port 12345
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
22:13:54.082215 IP A > B: Flags [S], seq 17057880, win 512, length 0
22:13:54.082249 IP B > A: Flags [S.], seq 2134046664, ack 77687439, win 29200, options [mss 1460], length 0
22:13:54.082259 IP A > B: Flags [R], seq 77687439, win 0, length 0
22:13:54.082510 IP B > A: Flags [R], seq 559655664, win 0, length 0
22:13:54.083072 IP B > A: Flags [R], seq 77687439, win 0, length 0
22:13:54.083079 IP A > B: Flags [S], seq 17057880, win 512, length 0
22:13:54.083094 IP B > A: Flags [S.], seq 2374986, ack 17057881, win 29200, options [mss 1460], length 0
。。。
SYN FLOOD 问题最简单的解决方法，就是从交换机或硬件防火墙中封掉源IP，这样SYN FLOOD网络帧就不会发送到服务器中了
软中断CPU使用率(softirq)升高是一种很常见的性能问题，虽然软中断的类型很多，但实际生产中，我们遇到的性能瓶颈大多是网络收发类型的软中断，特别是网络接收的软中断
借助sar，tcpdump可以做进一步的分析
参考