可以从以下链接查看配置文件的小案例系列哦
前言
中断
提供系统并发处理能力的异步事件处理机制
当发生中断事件时，将触发中断处理程序的执行
中断处理程序分为上半部分和下半部分
上半部分：硬中断、快速处理中断
下半部分)用于异步处理上半部分未完成工作的软中断
软中断
每个CPU都支持一个软中断内核线程，名称为ksoftirqd/CPU编号
如果软中断事件频率过高，内核线程也会因CPU使用率过高而导致软中断过程延迟，导致网络收发延迟、调度延迟等性能问题
软中断频率过高的案例
系统构成
Ubuntu18.04、2CPU、2GB内存，共两台虚拟机
三个工具
sar :使用系统活动报告工具，可以实时查看系统的当前活动，以及配置历史统计信息的存储和报告。
hping3:一个可以构建TCP/IP协议包的工具，可以对系统进行安全审核、防火墙测试等。
tcpdump :一种常见的网络捕获工具，常用于分析各种网络问题
虚拟机关系
在文件管理器中运行案例
在VM1中执行命令
docker run-itd---- name=nginx-p 80:80 nginx
用curl确认Nginx正常启动
在VM2上执行命令
curl http://172.20.72.58/
用hping3模拟Nginx客户端请求
在VM2上执行命令
hping3 -S -p 80 -i u100 172.20.72.58
-S :参数表示设定TCP协议的SYN (同步序列号)
-p :表示目标端口为80
-i:u100表示每100微秒发送一个网络帧
返回VM1
我觉得系统的响应明显变慢了。 即使在终端中敲几下滑架，也需要很长时间才能得到响应
分析为什么系统的响应会变慢
以下所有命令都在VM1上运行
使用top命令显示系统资源的使用情况
系统CPU使用率(用户状态us和内核状态sy )不高
平均负荷适中，只有两个r状态过程，没有僵尸过程
但是，软中断过程1号(ksoftirqd/1 )的CPU使用率较高，处理软中断过程的CPU比例达到94
此外，没有其他异常过程
可以推测软中断是一枚甜蜜的戒指
确认是什么类型的软中断
通过观察/proc/softirqs文件的内容，可以了解各种软中断类型的次数
这里的各种软中断次数是哪个时间段的次数呢？
这是系统运行以来的累计中断次数
所以直接查看文件的内容，得到的只是累计中断次数，对这里的问题没有直接参考的意义
中断次数的变化速度才值得关注
在watch上动态显示指令输出结果
因为我的机器是双内核的，所以直接导入/proc/softirqs会打印128个内核的信息，但对我来说，只要看到前面的两个内核的信息就足够了，所以我需要写重要的数据
watch -d '/故意的书包/cat /proc/softirqs | /usr/故意的书包/awk ' NR==1{ printf' %-15s %-15s
分析结果
定时中断(TIMER )、NET_RX )、SCHED )、rcu )、rcu锁)等软中断不断变化
另外一方面，NET_RX网络分组接收软中断的变化速度最快
其他几种类型的软中断在发生变化时是正常的，因为它们是确保Linux调度、时钟和关键节保护等正常运行所必需的
通过sar确认系统的网络收发状况
上面已经确认了从网络接收的软中断开始，所以第一步应该看系统的网络接收情况
sar的好处
不仅是网络发送和接收的吞吐量(BPS，每秒发送和接收的字节数)
还可以观察网络发送和接收的PPS (每秒发送和接收的网络帧数)
执行sar命令
sar -n DEV 1
列IFACE表示网卡
第三、四列： rxpck/s和txpck/s分别表示每秒发送和接收的网络帧数【PPS】
第五、六列： rxkB/s和txkB/s分别表示每秒发送和接收的千字节数【BPS】
分析结果
对网卡 ens33来说
每秒接收的网络帧数比较大，几乎达到 8w，而发送的网络帧数较小，只有接近 4w
每秒接收的千字节数只有 4611 KB，发送的千字节数更小，只有2314 KB
docker0和 veth04076e3
数据跟 ens33 基本一致只是发送和接收相反，发送的数据较大而接收的数据较小
这是Linux 内部网桥转发导致的，暂且不用深究，只要知道这是系统把 ens33 收到的包转发给 Nginx 服务即可
异常点
前面说到是网络数据包接收软中断的问题，那就重点看 ens33
接收的 PPS 达到 8w，但接收的 BPS 只有 5k 不到，网络帧看起来是比较小的
4611 * 1024 / 78694 = 64 字节，说明平均每个网络帧只有 60 字节，这显然是很小的网络帧，也就是常说的小包问题
灵魂拷问
如何知道这是一个什么样的网络帧，它又是从哪里发过来的呢？
通过 tcpdump 抓取网络包
已知条件
Nginx 监听在 80端口， 它所提供的 HTTP 服务是基于 TCP协议的
执行 tcpdump 命令
tcpdump -i ens33 -n tcp port 80
-i ens33：只抓取 ens33 网卡
-n：不解析协议名和主机名
tcp port 80：表示只抓取 tcp 协议并且端口号为 80 的网络帧
172.20.72.59.52195 > 172.20.72.58.80
表示网络帧从 172.20.72.59 的 52195 端口发 送到 172.20.72.58 的 80 端口
也就是从运行 hping3 机器的 52195 端口发送网络帧， 目的为 Nginx 所在机器的 80 端口
Flags [S]
表示这是一个 SYN 包
性能分析结果
结合 sar命令发现的 PPS 接近 4w 的现象，可以认为这就是从 172.20.72.59 这个地址发送过来的 SYN FLOOD 攻击
解决 SYN FLOOD 问题
从交换机或者硬件防火墙中封掉来源 IP，这样 SYN FLOOD 网络帧就不会发送到服务器中
后续的期待
至于 SYN FLOOD 的原理和更多解决思路在后面会讲到哦
分析的整体思路
系统出现卡顿，执行命令，响应也会变慢
通过 top查看系统资源情况
发现 CPU 使用率(us 和 sy)均不高，平均负载适中，没有超 CPU 核数的运行状态的进程，也没有僵尸进程
但是发现处理软中断的 CPU 占比(si)较高，在进程列表也可以看到软中断进程 CPU 使用率偏高，猜测是软中断导致系统变卡顿的主要原因
通过/proc/sorfirqs查看软中断类型和变化频率，发现直接 cat 的话会打印 128 个核的信息，但只想要两个核的信息
所以结合 awk进行过滤，再通过 watch命令可以动态输出查看结果
发现有多个软中断类型在变化，重点是 NET_RX变化频率超高，而且幅度也很大，它是网络数据包接收软中断，暂且认为它是问题根源
既然跟网络有关系，可以先通过 sar命令查看系统网络接收和发送的整体情况
然后可以看到接收的 PPS 会比接收的 BPS 大很多，做下运算，发现网络帧会非常小，也就是常说的小包问题
接下来，通过 tcpdump抓取 80端口的 tcp 协议网络包，会发现大量来自 VM2 发送的 SYN 包，结合 sar 命令，确认是 SYN FLOOD 攻击
本文分享 CNBlog - 阿菠萝阿瑶。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。