系统调用导致网络收包卡顿的问题分析

开发 前端
针对这个问题的分析持续了大约一、两个月的时间,期间也曾一度陷入迷惑而毫无进展,有初步分析思路后补充了操作系统内核的各种知识,主要包括进程调度、调度优先级、中断处理、网络协议栈处理、虚拟文件系统等等,最终可以将整个问题的来龙去脉解释清楚。

前言

G行某平台类应用系统提供高并发、低延迟的服务请求,该系统的的响应时间在1毫秒左右,目前最大TPS在2.5万左右,为保证该系统的快速响应,系统设置的超时时间为30毫秒。在一次巡检中发现,该系统的几台服务器超时交易笔数在逐渐增加,为避免系统运行风险,协调网络、操作系统等专家一同分析,在分析过程中补充学习了大量Linux操作系统内核的知识,现将分析过程及其中用到的知识点记录下来,以便为解决类似的问题提供一个通用的解决思路。

一、应用系统超时现象

外部系统将请求发送到前端服务,前端服务进行业务逻辑后重新组装报文,将请求发送到后端服务。交易处理超时体现在前端服务对后台服务的请求上,但是根据网络设备的镜像网络包分析,后端服务的处置时间没有异常,前端发送给后端的请求,后端都可以快速的处理。因此问题还是出现在前端服务上。

图片

图1 系统逻辑架构

由于该系统的交易量大、响应时间低,所以对处理过程的日志记录较少,根据前端服务的应用日志无法定位根本原因。针对前端服务到后台服务的请求,选一段超时交易较多的时间段的网络镜像包进行分析。发现超时交易集中在两个固定的时间点,分别为:11:29:4.200,超时9笔,平均TCPack_rtt为5毫秒;11:29:54.100,超时2笔,平均TCPack_rtt为6毫秒,在这两个时间段超时交易的rtt都大于30毫秒,没有超时的交易也有部分ack的rtt相对较长。其他正常交易时间段的ack_rtt在0.06毫秒左右。

图片

图2 网络镜像包异常现象

根据这个现象初步怀疑在网络收发包上出现了拥堵问题,操作系统网络协议栈对收到的网络包没有及时处理。具体处理过程为前端发送请求到后端服务,后端服务立即进行了响应并返回响应包,由于协议栈没有及时处理响应包,导致相应的ack包没有及时返回,同时导致前端服务没有及时收到后端服务的返回,从而出现超时的现象。

为验证怀疑的方向,将一台服务器进行物理重启,重启后超时现象消失;同时将另外一台服务器只重启应用系统,超时现象没有出现缓解。因此可以确定交易的超时现象是由于操作系统的原因导致,和应用系统的处理性能无关。

二、问题排查

由于怀疑和操作系统的协议栈处理有关,为便于问题排查,同时避免对生产的稳定运行造成影响,我们使用perf和hping3进行异常的复现和问题分析。perf是Linux的一款性能分析工具,能够进行系统内核函数级和指令级的热点查找,可以用来分析程序中热点函数的CPU占用率,从而定位性能瓶颈。Hping3是一个开源网络工具,通过rawSocket直接组装icmp、udp、tcp报文,并记录对方服务器的ack响应时间。

图片

图3 问题排查方案

分析方案是找同子网的另外一台服务器部署hping3工具,向异常服务器不停的发送tcp报文,并记录ack返回出现延迟的时间点。在异常的服务器上部署perf工具,跟踪操作系统的内核调用,以便发现异常点。通过hping3每1毫秒发送一个网络包,记录其收到ack包的时间,可以发现在1650140557这个时间点出现大量rtt时间较长的情况,分析perf工具采集的内核调用数据,可以发现在相同的时间点存在大量ss进程发起的请求,当时正在执行的系统调用函数为read,根据调用栈proc_reg_read可以定位为程序正在读取/proc目录下的文件内容。

图片

 

图片

图4 内核系统异常调用栈

由于生产服务器上部署了各种代理和大量的监控脚本,因此怀疑是由这些代理、监控脚本发起的ss命令调用,在系统中查找使用ss命令的脚本,可以发现调用ss的命令行为图5所示。

图片

图5 触发异常的shell调用

通过strace跟踪ss 调用过程,如图6所示。

图片

图6 trace跟踪ss调用过程

关注read处理较慢的系统调用,可以发现read处理时间超过10ms的地方共有5处,最长的处理时间在189ms;根据文件句柄号3,可以确认正在读取的文件为”/proc/slabinfo”。

图片

图7 ss命令系统调用的异常

至此可以确认网络包接收卡顿,是由于监控周期性调用ss命令导致。ss命令会读取/proc/slabinfo,而在读取的时候有部分read函数的系统调用处理较慢,从而影响了网络接收包的处理。

为进一步验证上述结论,我们将异常服务器上使用ss命令的监控脚本停止,并启动前端服务将其加入生产队列,经过长时间观察,未再发现超时现象。然后手工在服务器上连续执行几次cat /proc/slabinfo,可以发现超时现象再次出现。

三、深入分析原因

1.第一个疑问:为什么读取/proc/slabinfo会导致网络包接收卡顿?

网络协议栈接收tcp报文并自动返回ack,是操作系统在中断中处理的,优先级别较高,而用户读取/proc/slabinfo是一般的系统调用,为什么会影响内核的中断处理呢?首先需要了解一下Linux操作系统代码执行的几个上下文场景。

硬件中断上下文:优先级别最高,只要有硬件中断发生就会被立即执行,这里包括时钟中断、网卡中断;

软件中断上下文:在硬件中断执行完成或系统调用完成时执行,这个是操作系统内核核心代码执行的主要环境,包括进程调度,网络协议栈处理等等;

内核进程上下文:运行在内核态,但是受进程调度管理,按进程调度分配的时间片执行,超过执行的时间片就有可能被别的进程抢占而暂停执行;

用户进程上下文:这个是大部分应用程序执行的环境,受进程调度管理,按进程调度分配的时间片执行,超过执行的时间片会强制进行进程切换。

那他们的执行优先级是不是就是:硬件中断> 软件中断> 内核进程>  用户进程。实际并不完全是这样,由于硬件中断、软件中断、内核进程都运行在内核态,运行在相同的地址空间,所有的数据都是共享的,如果硬件中断强制中断软件中断的执行,软件中断强制中断内核进程的执行,那么有可能会导致内核数据的混乱或者导致各种死锁,为了保护临界数据的安全和完整性,软件中断可以关硬件中断,内核进程可以关闭硬件中断和软件中断。

在执行cat/proc/slabinfo时,首先程序运行在用户进程上下文,然后执行系统调用read被切换到内核进程上下文,由于slabinfo中存储的是内核的内存分配信息,在读取内存分配信息时为了保证数据的一致性,在内核进程上下文中关闭了硬件中断和软件中断。由于进程调度也是通过硬件中断中的时钟中断触发的,所以如果长时间的关闭硬件中断、软件中断,进程调度也不会被执行。如果read执行时间较长,关闭中断的时间就会比较长,该进程就会长时间占用CPU不释放,阻止了内核协议栈对网络收包的处理。

查看Linux内核代码/linux-3.0.101/mm/slab.c中的s_show函数,可看到如下关闭中断的代码

图片

图8 读取slabinfo时关闭中断的内核代码

2.第二个疑问:服务器具有40CPU,为什么一个ss命令就会阻止网络包的处理呢,理论上应还有另外39个CPU来处理?

这个涉及RPS(ReceivePacket Steering)和RFS(ReceiveFlowSteering)技术,其主要功能就将高速网卡产生的大量网络包分配到多核CPU分别进行处理,但是这个分配是预分配,根据socket四元组(源IP、源端口、目的IP、目的端口)分配到不同的CPU进行处理。ss命令在哪个CPU上执行,那么分配到这个CPU上的网络包处理就会出现卡顿。因此在生产环境的表现上也是只有部分网络包出现了卡顿,而不是所有的网络包都会产生卡顿。

3.第三个疑问:读取/proc/slabinfo为什么会慢?

Slab算法是以字节为单位管理内存,是内核的小内存管理算法。特点是基于对象进行管理。slab分配算法采用cache存储内核对象,把相同类型的对象归为一类,每当要申请这样一个对象,slab分配器就从一个slab列表中分配一个这样大小的单元出去,而当要释放时,将其重新保存在该列表中,而不是直接返回给伙伴系统,从而避免这些内碎片。slab分配器并不丢弃已分配的对象,而是释放并把它们保存在内存中。当以后又要请求新的对象时,就可以从内存直接获取而不用重复初始化。

通过cat /proc/slabinfo可以查看slab分配的内存情况,其中包含的信息主要为统计信息,包括每种对象内存的总个数、已分配的个数、每页内存的对象个数、占用的内存页数等等。这些统计信息是怎么来的呢?是内核中现成的统计数据吗?通过查看代码可以发现,是一个个累加汇总来的,如果内存对象的个数较多,那将是一个非常耗时的大循环。其内核代码如下:

图片

通过cat /proc/slabinfo | sort -n-k3的输出,查看一下哪些内存对象的个数较多。

图片

图9 slab内存对象数量

如图9所示占用比较高的几项是dentry、buffer_head、proc_inode_cache。dentry 是文件目录对inode映射的缓存;Buffer_head 是硬盘的块缓存;proc_inode_cache 是/proc目录下inode节点信息的缓存。dentry、proc_inode_cache分别达到了797万和388万,这个数据量非常大,导致在输出/proc/slabinfo时耗时较长。

4.第四个疑问:为什么重启服务器后网络包卡顿现象就消失,其后为什么会变慢呢?

重启后卡顿现象消失这个问题现在很容易回答,那就是由于重启后slab中的缓存信息全部释放了,对象个数较少,再统计slabinfo时处理较快,不会影响网络包的接收了。重启运行一段时间后会再出现卡顿现象,是由于slab中缓存的信息又变多了,那是谁导致slab缓存了大量信息呢?

slab中个数较多的内存对象是dentry和proc_inode_cache,在查看/proc目录下的文件时,操作系统会自动将目录信息和inode信息缓存到这两个对象。因此是有程序周期性的读取/proc目录下的文件导致这两个内存对象缓存个数增多的。再次跟踪一下ss命令可以发现ss命会扫描/proc下所有进程打开的文件句柄,包括socket链接。我们这台服务器经常保持数万的链接数,这些链接的存活时间最短只有几秒钟,最长也就几个小时。因此执行一次ss-lntp命令会缓存数万的proc_inode_cache和dentry,如果周期性的执行这个命令,打开的socket句柄又不停的发生变化,就会导致slab缓存的数量不断增长。

四、问题解决

通过上面的分析可以确认导致网络包卡顿的原因是:周期性的调用ss-lntp命令,同时这台服务器上的网络链接不断发生变化,使得slab中缓存了大量的内存对象,并且ss会读取/proc/slabinfo中的汇总信息,而slabinfo中的汇总信息是每次通过效率不高的一个个累加的方式获得,且累加时关闭了操作系统的中断处理,导致接收到的网络包无法及时处理。

因此可采取的解决方案:

(1)执行echo "2" > /proc/sys/vm/drop_caches ,强制操作系统回收inode和dentry中的缓存信息。这个命令执行期间会造成系统卡顿,卡顿时间为几秒到几分钟,关键业务运行期间需慎用;

(2)周期性重启服务器,释放slab中的缓存信息;

(3)停止周期性调用ss -lntp;

(4)对于ss命令,可以去掉 -p 参数,去掉这个参数后,ss将不再扫描/proc目录下的进程信息,不会导致slab中内存对象个数的增长。另外也可以升级到高版本的ss命令,在高版本的ss命令中已不再读取 /proc/slabinfo,因为这里面已没有可以获取的有效信息。下面是github中的commit信息。

图片

图10 GitHub中commit信息

总结

针对这个问题的分析持续了大约一、两个月的时间,期间也曾一度陷入迷惑而毫无进展,有初步分析思路后补充了操作系统内核的各种知识,主要包括进程调度、调度优先级、中断处理、网络协议栈处理、虚拟文件系统等等,最终可以将整个问题的来龙去脉解释清楚。

参考资料:

《如何调试Kubernetes集群中的网络延迟问题?》Theo Julienne 分布式实验室

《网卡多队列:RPS、RFS、RSS、FlowDirector(DPDK支持)》rtoax CSDN

https://rtoax.blog.csdn.net/article/details/108987658

https://github.com/shemminger/iproute2/commit/10f687736b8dd538fb5e2bdacf6bef2c690ee99d

责任编辑:武晓燕 来源: 匠心独运维妙维效
相关推荐

2015-10-12 10:48:16

Mac卡顿原因

2021-05-13 09:53:17

电脑卡顿硬盘文件夹

2021-11-28 21:26:39

Windows 7Windows微软

2019-07-01 15:46:35

云平台Kubernetes问题排查

2022-05-02 08:30:46

网络Wi-Fi

2020-10-16 08:02:00

Android系统

2021-10-13 06:03:12

网络带宽卡顿

2018-07-27 18:47:01

数据库MySQL线程

2016-10-11 17:38:40

WIFI网络卡顿

2021-07-30 06:35:14

网络卡顿WiFi路由器

2015-01-13 11:17:17

2013-02-27 10:39:41

网络丢包故障

2024-02-02 15:21:08

工具页面性能

2021-09-15 18:30:45

UnhookMe恶意软件安全工具

2021-06-02 09:37:24

Raid机器性能

2021-08-31 23:09:50

微信功能技巧

2011-04-15 10:49:16

2011-04-15 10:50:23

2015-01-21 15:52:37

Hyper-V交换机虚拟网络
点赞
收藏

51CTO技术栈公众号