由CPU高负载引发内核探索之旅

导语：STGW（腾讯云CLB）在腾讯云和自研业务中承担多种网络协议接入、请求加速、流量转发等功能，有着业务数量庞大、接入形式多样、流量规模巨大的特点，给产研团队带来了各种挑战，经常要深入剖析各种疑难杂症。本文介绍了STGW在实际运营过程中，一次没有造成业务影响的CPU高负载被发现后，团队进行深入分析从内核端口发现问题根源，在经过与内外部linux内核专家们共同协作，输出解决方案并最终修复问题。

一、问题起源

值班期间，运维同学偶然发现一台机器CPU消耗异常，从监控视图上看出现较多毛刺。而属于同一集群的其他机器在同一时间段CPU消耗相对稳定。

从机器维度的监控无法掌握更多的信息，通过自建的秒级监控系统，我们拿到了更多的性能数据。实际的消耗情况比机器监控上看到的更加严重，高负载来自于sys消耗，全核cpu都被内核彻底消耗掉了。

秒级监控除了会捕获细粒度的系统负载外，针对发生高负载场景，会触发分析工具进行分析。虽然高负载发生的时间很短，依靠这套系统我们先拿到了导致高负载的直接原因，发生在inet_hash_connect函数中。

二、关于inet_hash_connect

inet_hash_connect这个函数是内核处理tcp连接的必经之路。我之前一篇关于高负载的文章也分析了tcp连接引发的该函数单核高负载的场景，详见：从STGW流量下降探秘内核收包机制，当时引发问题的函数是inet_lookup_listener。
不同点在于，inet_lookup_listener是服务端收到新连接时寻找监听端口，而inet_hash_connect函数是主动建立tcp连接，对应到我们的场景，就是STGW服务器与后端RealServer（后面简称RS）建立连接。
通过内核代码分析，该函数的简化流程如下，其作用是tcp连接主动选取一个端口，检查可用后，进行bind绑定操作，该端口即发起方用于收发连接数据的端口。

// 主动发起tcp连接
connect(fd, servaddr, addrlen);
-> sock->ops->connect() == inet_stream_connect
-> tcp_v4_connect()
    -> inet_hash_connect()
        -> __inet_hash_connect()
           /*
           如果指定了port，则使用指定的port作为客户端端口
           否则，随机选取一个port
           */
           // 端口可用性检查
             -> check_established()
           // bind端口
             -> inet_bind_bucket_create
             -> inet_bind_hash       

为什么inet_hash_connect会出现高负载？
从perf看，直接原因是raw_spin_lock锁带来的剧烈消耗，我们先找到这个锁所在位置，根据对应内核源码找inet_hash_connect实现及内部调用中，发现只有inet_check_establish里会进行spin_lock（其他几处为spin_lock_bh，如果是其他地方，应该为raw_spin_lock_bh）。

三、前期排查

通常锁造成高负载我们会怀疑是否有死锁产生，从cpu现象来看只是短时间突增并非死锁。那么我们有另外两种猜想：
1. 锁覆盖的范围执行极慢，导致锁了很长时间。
2. 频繁执行该函数执行加锁导致高负载。
先看第一种情况，我们假设inet_check_establisted函数中加锁区域代码执行效率慢，导致高负载。
分析代码容易看出，加锁部分是一个遍历哈希链表的操作，通过传入的参数计算一个哈希值，拿到哈希桶后遍历其中可用的节点，这种遍历操作确实值得怀疑，历史case告诉我们，哈希桶挂载的节点非常多导致遍历复杂度急剧上升，拖累整个cpu。例如