由 CPU 高负载引发内核探索之旅
作者：腾讯应用框架团队
STGW（七层 CLB）在公司云和自研业务中承担多种网络协议接入、请求加速、流量转发等功能，有着业务数量庞大、接入形式多样、流量规模巨大的特点，给我们带来了各种挑战，经常要深入剖析各种疑难杂症。本文介绍了在实际运营过程中，一次没有造成业务影响的 CPU 高负载被发现后，进行深入分析最终发现是内核端口查找的问题，经过了与社区 linux 内核专家确认、与公司 Tlinux 团队研讨，最终给出解决方案并修复问题。
一、问题起源
值班期间，运维同学偶然发现一台机器 CPU 消耗异常，从监控视图上看出现较多毛刺。而属于同一集群的其他机器在同一时间段 CPU 消耗相对稳定。
从机器维度的监控无法掌握更多的信息，通过自建的秒级监控系统，我们拿到了更多的性能数据。实际的消耗情况比机器监控上看到的更加严重，高负载来自于 sys 消耗，全核 cpu 都被内核彻底消耗掉了。
秒级监控除了会捕获细粒度的系统负载外，针对发生高负载场景，会触发分析工具进行分析。虽然高负载发生的时间很短，依靠这套系统我们先拿到了导致高负载的直接原因，发生在 inet_hash_connect 函数中。
二、关于 inet_hash_connect
inet_hash_connect 这个函数是内核处理 tcp 连接的必经之路。我之前一篇关于高负载的文章也分析了 tcp 连接引发的该函数单核高负载的场景，当时引发问题的函数是 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 现象来看只是短时间突增并非死锁。那么我们有另外两种猜想：
- 锁覆盖的范围执行极慢，导致锁了很长时间。
- 频繁执行该函数执行加锁导致高负载。
先看第一种情况，我们假设 inet_check_establisted 函数中加锁区域代码执行效率慢，导致高负载。
分析代码容易看出，加锁部分是一个遍历哈希链表的操作，通过传入的参数计算一个哈希值，拿到哈希桶后遍历其中可用的节点，这种遍历操作确实值得怀疑，历史 case 告诉我们，哈希桶挂载的节点非常多导致遍历复杂度急剧上升，拖累整个 cpu。例如从 STGW 流量下降探秘内核收包机制中分析到，由于哈希桶数量太少，当监听端口足够多时，遍历效率太低导致高负载的案例。
因此，这里合理怀疑是否是 ehash（TCP Established hash table）桶遍历太久，导致加锁时间过长？
根据之前的经验，我习惯性先找哈希桶初始化地方，尝试看这个问题是否如之前一般由哈希桶数量太少导致，在 tcp.c 文件的 tcp_init 函数中找到其初始化函数。
发现 ehash 的桶大小是由 alloc_large_system_hash 为其申请的空间，而该函数实现较为晦涩，引入了根据机器物理内存大小动态调整申请空间，很难通过代码直接看出到底分配了多大数量的哈希桶。好在函数最后会向系统日志打印出此次申请的哈希桶的大小。
pr_info("%s hash table entries: %ld (order: %d, %lu bytes)\n",
tablename, 1UL << log2qty, ilog2(size) - PAGE_SHIFT, size);
根据代码中的打印方式在机器上果然找到对应日志，从而得知 ehash table 的桶超过了 100w 个
这意味着在哈希均匀的情况下，ehash table 可以容纳百万条 establish 状态的连接，不会出现遍历热点。
而高负载服务器的连接数峰值大概 50w 左右，远没有达到阈值。
根据经验，另外一个猜想是：存在不均匀的流量，ehash 计算的哈希值可能都是同一个或几个，导致大量连接都落到了少数几个桶里，这种也有可能导致高负载。
通过监控和日志分析，确实发现 STGW 服务器与某个 RS（RealServer）连接数较大，超过了 2w 个连接。（客户转发规则仅配置了一个 RS，因此 STGW 收到的请求，都只能向这个 RS 发起连接并转发数据）。
那么往单个 RS 建立连接数过多会造成哈希桶使用不均匀吗？
static inline unsigned int __inet_ehashfn(const __be32 laddr,
const __u16 lport,
const __be32 faddr,
const __be16 fport,
u32 initval)
{
return jhash_3words((__force __u32) laddr,
(__force __u32) faddr,
((__u32) lport) << 16 | (__force __u32)fport,
initval);
}
从代码看，ehash table 在查找和插入过程计算哈希值都是通过 TCP 四元组进行哈希，而至少源端口这里是足够散列的，因此理论上不存在往同一个桶插入过多节点的情况。
四、峰回路转
此时回过头看，我们一直在问题机器上折腾，但还有个关键信息一直没有被深入挖掘，如图
根据运维同学提醒，同集群有另外一种机型可以作为参照，高负载仅出现在其中一种代号为 25G 的机型上，也就是说，承担了同样的转发流量，另外一种 10G 机型却并没有高负载出现。
根据这个线索，我们排查对比了集群内两种机型的异同点，首先流量大小、请求成分这些都是一致的，而网卡型号、CPU 型号、内核版本这些都是不一样的，根据上面的排查，CPU 高负载的热点主要在内核协议栈函数中，于是我们主要对比不同内核版本的实现差异。
发现不同内核版本在 inet_hash_connect 函数实现上，确实有明显区别。
- 先来看不出问题的机型，其内核版本为基于 3.10.107 的 tlinux2-0053
// Linux 3.10.107 x86_64 GNU/Linux
int __inet_hash_connect(struct inet_timewait_death_row *death_row,
struct sock *sk, u32 port_offset,
int (*check_established)(struct inet_timewait_death_row *,
struct sock *, __u16, struct inet_timewait_sock **),
int (*hash)(struct sock *sk, struct inet_timewait_sock *twp))
{
struct inet_hashinfo *hinfo = death_row->hashinfo;
const unsigned short snum = inet_sk(sk)->inet_num;
struct inet_bind_hashbucket *head;
struct inet_bind_bucket *tb;
int ret;
struct net *net = sock_net(sk);
int twrefcnt = 1;
if (!snum) { // 未指定端口
int i, remaining, low, high, port;
static u32 hint;
u32 offset = hint + port_offset;
struct inet_timewait_sock *tw = NULL;
// 获取本地可用端口范围
// 统一配置的10241 ~ 59999
inet_get_local_port_range(net, &low, &high);
remaining = (high - low) + 1;
local_bh_disable();
// remaining 即为 local_port_range规定的端口数量
for (i = 1; i <= remaining; i++) {
int ret;
// 注意：选取的port是逐次递增1，最多执行remaining次
port = low + (i + offset) % remaining;
if (inet_is_reserved_local_port(port))
continue;
head = &hinfo->bhash[inet_bhashfn(net, port,
hinfo->bhash_size)];
ret = spin_trylock(&head->lock);
if (!ret)
continue;
/* Does not bother with rcv_saddr checks,
* because the established check is already
* unique enough.
*/
inet_bind_bucket_for_each(tb, &head->chain) {
if (net_eq(ib_net(tb), net) &&
tb->port == port) {
if (tb->fastreuse >= 0 ||
tb->fastreuseport >= 0)
goto next_port;
WARN_ON(hlist_empty(&tb->owners));
// 检查端口是否可用
if (!check_established(death_row, sk,
port, &tw))
goto ok;
goto next_port;
}
}
tb = inet_bind_bucket_create(hinfo->bind_bucket_cachep,
net, head, port);
if (!tb) {
spin_unlock(&head->lock);
break;
}
tb->fastreuse = -1;
tb->fastreuseport = -1;
goto ok;
next_port:
spin_unlock(&head->lock);
}
local_bh_enable();
return -EADDRNOTAVAIL;
/* 省略部分问题无关代码 */
}
- 问题机型的内核版本基于 4.14.105 版本，该版本相较于上述更先进，其中函数实现如下
// Linux 4.14.105-1 x86_64 GNU/Linux
int __inet_hash_connect(struct inet_timewait_death_row *death_row,
struct sock *sk, u32 port_offset,
int (*check_established)(struct inet_timewait_death_row *,
struct sock *, __u16, struct inet_timewait_sock **))
{
struct inet_hashinfo *hinfo = death_row->hashinfo;
struct inet_timewait_sock *tw = NULL;
struct inet_bind_hashbucket *head;
int port = inet_sk(sk)->inet_num;
struct net *net = sock_net(sk);
struct inet_bind_bucket *tb;
u32 remaining, offset;
int ret, i, low, high;
static u32 hint;
/*省略部分无关代码*/
inet_get_local_port_range(net, &low, &high);
high++; /* [32768, 60999] -> [32768, 61000[ */
// remaining为local_port_range规定的端口数量
remaining = high - low;
if (likely(remaining > 1))
remaining &= ~1U;
offset = (hint + port_offset) % remaining;
/* In first pass we try ports of @low parity.
* inet_csk_get_port() does the opposite choice.
*/
// 注意：这里意味着，如果offset为奇数，强制变成偶数
offset &= ~1U;
other_parity_scan:
// 注意：由于offset第一次必为偶数，port的奇偶性完全取决于low
// (注：下面会goto other_parity_scan，再次回到这里，奇偶性反转)
port = low + offset;
// 注意：该循环每次递增2，意味着只会查询remaining/2个端口，并且这些端口奇偶性与port初始值一致
for (i = 0; i < remaining; i += 2, port += 2) {
int ret;
if (unlikely(port >= high))
port -= remaining;
if (inet_is_local_reserved_port(net, port))
continue;
head = &hinfo->bhash[inet_bhashfn(net, port,
hinfo->bhash_size)];
ret = spin_trylock_bh(&head->lock);
if (!ret)
continue;
/* Does not bother with rcv_saddr checks, because
* the established check is already unique enough.
*/
inet_bind_bucket_for_each(tb, &head->chain) {
if (net_eq(ib_net(tb), net) && tb->port == port) {
if (tb->fastreuse >= 0 ||
tb->fastreuseport >= 0)
goto next_port;
WARN_ON(hlist_empty(&tb->owners));
if (!check_established(death_row, sk,
port, &tw))
goto ok;
goto next_port;
}
}
tb = inet_bind_bucket_create(hinfo->bind_bucket_cachep,
net, head, port);
if (!tb) {
spin_unlock_bh(&head->lock);
return -ENOMEM;
}
tb->fastreuse = -1;
tb->fastreuseport = -1;
goto ok;
next_port:
spin_unlock_bh(&head->lock);
cond_resched();
}
// 注意：循环结束后，走到这里意味着依然没有找到合适的端口
// 此时将offset的奇偶性改变，通过goto返回上面循环，重新查找可用端口
offset++;
if ((offset & 1) && remaining > 1)
goto other_parity_scan;
return -EADDRNOTAVAIL;
/*省略部分问题无关代码*/
}
从前面的内容交代过，inet_hash_connect 的一个最重要的功能就是选取本地 socket 的端口并且检查其是否可用。从上述两段不同内核代码分析，很明显在端口选取实现两个内核差异很大。具体差别总结如下：
- 3.10 内核不出问题：其端口选取过程为 for 循环在 port_offset 基础上逐次递增 1，直到找到可用端口为止，或者超过了 local_port_range 个数，则返回 EADDRNOTAVAIL
- 4.14 内核出现高负载问题：其端口选取过程为 for 循环在 port_offset 基础上逐次递增 2，只把奇数范围（取决于 local_port_range 左边界）端口进行遍历，如果整个奇数范围都找不到可用端口，再遍历所有偶数端口，直到找到可用端口为止，或者超过了 local_port_range 个数，则返回 EADDRNOTAVAIL。
进一步分析：4.14 内核做了奇偶区分，每次递增 2 就是为了只找奇数或偶数的端口，这种遍历方式乍一看似乎没毛病，因为可用端口总数限定了（local_port_range），在 port_offset 初始值 Z 足够离散的情况下，遍历过程不管递增 1 还是递增 2，应该是差不多的，都有概率在递增后碰到可用端口。
上面提到，我们的问题服务器，有一个业务只绑定了一个 RS，在高负载的时候，服务器与这个 RS 建立的连接超过了 2w 条。结合这个现象，很快发现了问题所在，由于我们的 local_port_range 为 10241~59999，总的可用端口数为 49758 个，其中奇数、偶数分别占 2.4 万多个。
所以，问题基本可以确认，高负载期间，问题服务器与该 RS 建立了 2w 多条连接，实际上将 inet_hash_connect 中的奇数端口几乎耗尽，然而每次与该 RS 建立新连接，内核都要首先遍历奇数端口，进行 2w 多次无效的端口查找与检查（inet_check_establish 进行 spin_lock），才有可能开始遍历偶数端口，从而找到可用端口。
相比之下，3.10 内核的实现，在 49758 个端口内查找，即便是已经有 2w 多个端口不可用了，借助于 port_offset（port_offset 基于源+目的地址进行散列）加上 hint 记录上一次找到的位置（感谢 neilsylin 的指出之前描述的错误），做到足够分散，平均下来每次都可以较快找到可用的端口。
五、复现验证
为了最终确认这个问题，我们将现象及分析同步给了系统测试同学及 tlinux 研发，tlinux 同学帮忙修改了 4.14 内核中的 inet_hash_connect 函数，使其不再按奇偶性选择端口，帮忙打包了一个 4.14.105 内核修复版。
系统测试同学对比测试了 4.14.105 原版本 vs 4.14.105 修复版，结果如下：
- 原版本向 RS 172.16.0.1:20000 建立 2.8w 条连接后，连接数很难继续上升，同时 CPU 全核出现 sys 高负载，perf 发现就是 inet_hash_connect 导致
- 新内核版本，对于单个RS，可以打到4.3w条连接以上，CPU不出现高负载，消耗最大的是usr中SSL握手消耗。
六、溯源
到这里，我们在理论上与实践上都证实了，问题是由于更先进的内核（4.14 版本）修改了 inet_hash_connect 中选取端口的遍历逻辑，优先遍历奇数或者偶数端口，当服务器与单个 RS 建连数量超过 local_port_range/2 后就会导致无效遍历过多从而 cpu 高负载。
所以，为什么 linux 官方要将选端口逻辑改成奇偶遍历呢？通过 git 修改历史，很快定位到了提交点。
如图，在 4.6 版本开始，Google 内核协议栈专家提交了两个 commit，将可用端口按奇偶划分两部分，一部分给 connect 使用，另一部分给 bind 使用。我们追溯了一下 bind 的实现（细节可参见 inet_csk_get_port）发现确实与 inet_hash_connect 做了类似的操作，只不过一个是取奇数另一个取偶数。
结合自身情况来看，我们并没有随机 bind 端口的场景（例如 listen 端口，一般都是指定端口进行监听，不存在随机的情况）。因此进一步找了作者确认。
作者给我的回信明确了对于不需要 bind()随机端口的用户，这个方式是有害的。同时只提到是 google 需要大量随机 bind()，为了避免频繁发生事故加了这个功能，但 google 到底什么场景需要如此频繁的随机 bind，没有给明确回应。
七、解决问题
即便找到了原作者反馈问题，他并不乐意进一步做方案优化，而是让我们自己按需解决。对于这个问题，我们从短期到长期给出的解决方案如下：
短期方案
通过增加四元组的数量缓解问题，该问题实际上是源地址+目的地址+目的端口都确定的情况下，新连接只能从本地端口这一个维度进行扩展。即便没有高负载问题（老版本内核）连接数也无法超过 5w（受限于 local_port_range）。因此，可以通过拓宽四元组的另外维度，来大幅度提升可建立的连接数，具体有三个办法：
- 增加后端 RS 数量：扩展目的地址数量
- 增加后端 RS 端口数：扩展目的端口数量
- 增加客户端机器本地地址数量：扩展源地址数量
最终方案
在腾讯的tlinux系统中，已进行优化内核奇偶遍历逻辑，给用户更自由的端口分配权限，彻底解决该问题。
总结
最后，总结整个问题和定位过程，我们从一次 CPU 高负载问题出发，从最开始在问题机器上猜想和分析，找不到确切答案。通过比较不同机型函数实现差异找到关键点。再通过代码分析、复现验证、社区求证这三个方面将问题的前因后果分析清楚，最终给出了解决方案。
