中断是系统用来响应硬件设备请求的一种机制，它会打断进程的正常调度和执行，然后调用内核中的中断处理程序来响应设备的请求。中断其实是一种异步的事件处理机制，可以提高系统的并发处理能 力。
由于中断处理程序会打断其他进程的运行，所以，为了减少对正常进程运行调度的影响，中 断处理程序就需要尽可能快地运行。
中断处理程序在响应中断时，还会临时关闭中断。这就会导致上一次中断处理完成 之前，其他中断都不能响应，也就是说中断有可能会丢失。
为什么有硬中断和软中断区分?
为了解 决中断处理程序执行过长和中断丢失的问题，****Linux 将中断处理过程分成了两个阶段，也就 是上半部和下半部：
- 上半部直接处理硬件请求， 硬中断，特点是快速执行；
- 网卡接收到数据包后：
- 会通过硬件中断的方式，通知内核有新的数据到了。
- 同时把网卡的数据读到内存中，然后更新一下硬件寄存器的状态（表示数据已经读好了），最后再发送一个软中断信号，通知下半部做进一步 的处理。
- 硬中断是硬件产生的,比如键盘、鼠标的输入，硬盘的写入读取、网 卡有数据了；
- 网卡接收到数据包后：
- 下半部则是由内核触发， 软中断，特点是延迟执行。通常以内核线程的方式运行。
- 内核就应 该调用中断处理程序来响应它。
- 下半部被软中断信号唤醒后，需要从内存中找到网络数据，再按照网络协议栈，对数据进 行逐层解析和处理，直到把它送给应用程序。
- 软中断是软件产生的，比如程序内的定时器、RCU锁等
- 上半部会打断 CPU 正在执行的任务，然后立即执行中断处理程序。
- 下半部以内核线程的方式执行，并且每个 CPU 都对应一个软中断内核线程，名字为 “ksoftirqd/CPU 编号”，比如说， 0 号 CPU 对应的软中断内核线程的名字就是 ksoftirqd/0。
软中断不只包括了硬件设备中断处理程序的下半部，一些内核 自定义的事件也属于软中断，比如内核调度和 RCU 锁（Read-Copy Update 的缩写， RCU 是 Linux 内核中最常用的锁之一）等。
查看软中断
proc 文件系统。它是一种内核空间和用户空间进行通 信的机制，可以用来查看内核的数据结构，或者用来动态修改内核的配置。
/proc/softirqs 提供了软中断在不同 CPU 上的累积运行次数
/proc/interrupts 提供了硬中断在不同 CPU 上的累积运行次数
- 注意软中断的类型，也就是这个界面中第一列的内容。从第一列你可以看到，软中 断包括了 10 个类别，分别对应不同的工作类型。比如 NET_RX 表示网络接收中断，而 NET_TX 表示网络发送中断。
- 同一种软中断在不同 CPU 上的分布情况，也就是同一行的内容。正常情况 下，同一种中断在不同 CPU 上的累积次数应该差不多
查看软中断内核线程 softirqd
- 软中断实际上是以内核线程的方式运行的，每个 CPU 都对应一个软中 断内核线程，这个软中断内核线程就叫做 ksoftirqd/CPU 编号。
这些线程的名字外面都有中括号，这说明 ps 无法获取它们的命令行参数 （cmline）。一般来说，ps 的输出中，名字括在中括号里的，一般都是内核线程。
软中断CPU使用率升高
hping3 是一个可以构造 TCP/IP 协议数据包的工具，可以对系统进行安全审计、防火墙 测试等。
sar 是一个系统活动报告工具，既可以实时查看系统的当前活动，又可以配置保存和报告历史统计数据。
tcpdump 是一个常用的网络抓包工具，常用来分析各种网络问题。
shell输入命令变慢分析
top 看看是不是出现了 CPU 的瓶 颈
两个 CPU 的使用率虽然分别只有 3.3% 和 4.4%，但都用在了软中断 上；而从进程列表上也可以看到，CPU 使用率最高的也是软中断进程 ksoftirqd
判断哪类软中断的问题
观察 /proc/softirqs 文件的内容，你就能知道各种软中断类型的次数。但这是系统运行以来的累积中断 次数。
watch 命令，就可以定期运行一个命令来查看输出；如果再加上 -d 参数，还可以高亮出变 化的部分，从高亮部分我们就可以直观看出，哪些内容变化得更快。
**watch -d cat /proc/softirqs**
TIMER（定时中断）、 NET_RX（网络接收）、SCHED（内核调度）、RCU（RCU 锁）等这几个软中断都在不停 变化。网络数据包接收软中断的变化速率最快。而其他几种类型的软中 断，是保证 Linux 调度、时钟和临界区保护这些正常工作所必需的，所以它们有一定的变 化倒是正常的。
观察系统的网络接收情况
sar 可以用来查看系统的网络收发情况，不仅可以观察网络收发的吞吐量 （BPS，每秒收发的字节数），还可以观察网络收发的 PPS，即每秒收发的网络帧数。
第一列：表示报告的时间。
第二列：IFACE 表示网卡。
第三、四列：rxpck/s 和 txpck/s 分别表示每秒接收、发送的网络帧数，也就是 PPS。
第五、六列：rxkB/s 和 txkB/s 分别表示每秒接收、发送的千字节数，也就是 BPS。
- 对网卡 eth0 来说，每秒接收的网络帧数比较大，达到了 12607，而发送的网络帧数则比 较小，只有 6304；每秒接收的千字节数只有 664 KB，而发送的千字节数更小，只有 358 KB。
- docker0 和 veth9f6bbcd 的数据跟 eth0 基本一致，只是发送和接收相反，发送的数据 较大而接收的数据较小。这是 Linux 内部网桥转发导致的。
怀疑是网络接收中断的问题，看 eth0 ：接收的 PPS 比较大，达到 12607，而接收的 BPS 却很小，只有 664 KB。直观来看网络帧应该都是比较小的，664*1024/12607 = 54 字节，说明平均每个网络帧只有 54 字节，这显然是 很小的网络帧，也就是我们通常所说的小包问题。
网络抓包验证小包猜测
使用 tcpdump 抓取 eth0 上的包就可以了。我们事先已经知道， Nginx 监听在 80 端口， 它所提供的 HTTP 服务是基于 TCP 协议的，所以我们可以指定 TCP 协议和 80 端口精确抓 包：
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 网络帧就不会发送到服务器中。
