我们先继续说一下中断,中断分为了上半部分和下半部分
上半部分对应硬中断,用于处理快速中断,接收信号
下半部分对应软中断,异步处理上半部分没有完成的工作
Linux中的软中断包括网络收发,定时,调度,RCU锁等类型,可以通过查看proc文件系统中的/proc/softirqs,观察软中断的运行情况
Linux中,每个CPU都对应着一个软中断内核线程,名为ksoftirqd/CPU编号,软中断事件频率过高,会导致网络延迟等问题
今天就是拿一个NGINX来进行分析这类问题
我们这次使用的工具是 sar hping3 tcpdump,进行讲解
这三个工具的功能如下
sar 是一个系统活动报告工具,查看当前系统活动,以及配置保存和报告历史数据
hping3 是一个构造TCP IP协议数据包的工具,系统进行安全审计,防火墙测试的工具
tcpdump用于网络抓包工具,分析各种网络问题
本次仍然是一台虚拟机运行Nginx,模拟待分析的Web服务器,另一台用来给Nginx增加请求压力
对应的操作如下
我们利用hping3工具,来模拟Nginx的客户端请求
hping3 -S -p 80 -i u100 192.168.0.30
-S说明是设置TCP协议的SYN同步序列号,-p代表目的端口 80
-i u100 表示每隔100微秒发送一个网络帧
在原本运行Nginx的终端上,会发现系统响应变慢了,我们如果看到了hping3,会发现这是一个标注你的SYN FLOOD攻击,那么我们先抛开这个看法,看一下如何排查
首先进行排查,需要我们看一下系统的整体资源使用情况,执行一下top是否出现了CPU的瓶颈,我们尝试运行top命令,看一下系统整体的资源使用情况
top
看一下异常的现象
平均负载全是0,就绪队列只有一个进程
每个CPU的使用率都很低,最高的CPU1的使用率只有4.4%,并不算高
看一下进程列表,CPU使用率最高的进程只有0.3%,不算高
那么指标和性能如何挂钩呢?
看top的输出,两个CPU的使用率只有3.3%和4.4%,而且都在软中断上,从进程列表上可以看到,CPU使用率最高的也是软中断进程ksoftirqd,软中断的确可疑
软中断有问题的话,我们需要看是哪种软中断的问题,我们可以观察 /proc/softirqs文件的内容
不过文件中记录的软中断次数,是累计的软中断次数,对我们没有直接的意义,我们需要使用watch命令来进行查看输出,
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 |
通过 /proc/softirqs文件内容的变化情况,常见的中断有 定时中断 网络接收 RCU锁 SCHED内核调度
NET_RX是指的网络包接收,这个网络接收的软中断,是我们接下来着重查看的目标
我们利用今天的主角工具 sar来进行查看
sar可以查看系统的网络收发情况,可以观察网络收发的吞吐量,观察网络收发的PPS,每秒收发的帧数
我们运行sar命令,添加-n DEV参数来显示网络收发的报告
|
$ 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 |
对应的输出解释如下
第一列,表示报告的时间
第二列,表示网卡
第三第四列,rxpck/s txpck/s 表示每秒的接收,发送的网络帧数,PPS
第五第六列,rxkB/s txkB/s 表示每秒接收发送的千字节数,BPS
对于网卡eth0来说,网络帧数比较大,达到了12607,发送的网络帧数比较小,只有6405,千字节数更小,只有358KB
对于这些数据,有什么疑问,有什么办法知道这是一个网络帧吗,以及从哪里来的?
使用tcpdump抓取eth0上的包就可以了,事先已经知道,Nginx监听在80端口.其提供的HTTP服务是基于TCP协议的,指定TCP协议和80端口进行抓包
接下来我们进行tcpdump命令,通过-i eth0制定网卡eth0
通过tcp port80指定了80端口的TCP协议
|
# -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 … |
tcpdump -i eth0 -n tcp port 80
tcpdump的输出中,可以发现
上面的输出中,看到了来源机器ip,以及 Flags[S],表明这是一个SYN包
加上sar发现的上面看出PPS超过12000,说明是一个SYN FLOOD攻击
那么解决SYN FLOOD问题最简单的解决方案,就是从交换机或者硬件防火墙中封掉来源IP,这样SYN FLOOD就不会发送到服务器中
最后,别忘了停止hping3命令,在第一个终端中,运行Ctrl +C就可以停止hping3了
软中断CPU使用率 softirq升高很常见,虽然软中断的类型多,但是实际生产中,性能瓶颈往往是网络收发的软中断
那么本次,这样软中断是啥类型呢?
这次的案例问题其实很简单,SYN必然会触发网络的软中断,网络的软中断上去了,必然会导致对应的网络延迟增加,以至于网络延迟增加,从而导致远程终端访问变慢