解 Bug 之路 -Nginx 502 Bad Gateway

前言

事实证明，读过 Linux 内核源码的确有很大的益处，尤其在解决问题的时刻。当你看到报错的那一瞬间，就能把景象 / 起因 / 以及解决方案一股脑的在脑中闪现。甚至一些边边角角的景象都能很快的反馈过去是为何。笔者读过一些 Linux TCP 协定栈的源码，就在解决上面这个问题的时候有一种十分晦涩的感觉。

Bug 现场

首先，这个问题其实并不难解决，然而这个问题引发的景象倒是挺有意思。先形容一下景象吧，
笔者要对自研的 dubbo 协定隧道网关进行压测 (这个网关的设计也挺有意思，筹备放到前面的博客外面)。先看下压测的拓扑吧:

为了压测笔者 gateway 的单机性能，两端仅仅各保留一台网关，即 gateway1 和 gateway2。压到肯定水平就开始报错，导致压测进行。很天然的就想到，网关扛不住了。

网关的状况

去 Gateway2 的机器上看了一下，没有任何报错。而 Gateway1 则有大量的 502 报错。502 是 Bad Gateway，Nginx 的经典报错，首先想到的就是 Gateway2 不堪重负被 Nginx 在 Upstream 中踢掉。

那么，就先看看 Gateway2 的负载状况把，查了下监控，发现 Gateway2 在 4 核 8G 的机器上只用了一个核，齐全看不出来有瓶颈的样子，难道是 IO 有问题？看了下小的可怜的网卡流量打消了这个猜测。

Nginx 所在机器 CPU 利用率靠近 100%

这时候，发现一个有意思的景象,Nginx 确用满了 CPU!

再次压测，去 Nginx 所在机器上 top 了一下，发现 Nginx 的 4 个 Worker 别离占了一个核把 CPU 吃满 -_-!

什么，号称性能强悍的 Nginx 居然这么弱，说好的事件驱动 epoll 边际触发纯 C 打造的呢？肯定是用的姿态不对！

去掉 Nginx 间接通信毫无压力

既然猜想是 Nginx 的瓶颈, 就把 Nginx 去掉吧。Gateway1 和 Gateway2 直连，压测 TPS 外面就飙升了，而且 Gateway2 的 CPU 最多也就吃了 2 个核，毫无压力。

去 Nginx 上看下日志

因为 Nginx 机器权限并不在笔者手上，所以一开始没有关注其日志，当初就分割一下对应的运维去看一下吧。在 accesslog 外面发现了大量的 502 报错，的确是 Nginx 的。又看了下谬误日志，发现有大量的

Cannot assign requested address

因为笔者读过 TCP 源码，一瞬间就反馈过去，是端口号耗尽了！因为 Nginx upstream 和后端 Backend 默认是短连贯，所以在大量申请流量进来的时候回产生大量 TIME_WAIT 的连贯。

而这些 TIME_WAIT 是占据端口号的，而且根本要 1 分钟左右能力被 Kernel 回收。

cat /proc/sys/net/ipv4/ip_local_port_range
32768    61000

也就是说，只有一分钟之内产生 28232(61000-32768)个 TIME_WAIT 的 socket 就会造成端口号耗尽，也即 470.5TPS(28232/60), 只是一个很容易达到的压测值。事实上这个限度是 Client 端的,Server 端没有这样的限度，因为 Server 端口号只有一个 8080 这样的有名端口号。而在
upstream 中 Nginx 表演的就是 Client, 而 Gateway2 就表演的是 Nginx

为什么 Nginx 的 CPU 是 100%

而笔者也很快想明确了 Nginx 为什么吃满了机器的 CPU, 问题就进去端口号的搜寻过程。

让咱们看下最耗性能的一段函数:

int __inet_hash_connect(...)
{
        // 留神，这边是 static 变量
        static u32 hint;
        // hint 有助于不从 0 开始搜寻，而是从下一个待调配的端口号搜寻
        u32 offset = hint + port_offset;
        .....
        inet_get_local_port_range(&low, &high);
        // 这边 remaining 就是 61000 - 32768
        remaining = (high - low) + 1
        ......
        for (i = 1; i <= remaining; i++) {port = low + (i + offset) % remaining;
            /* port 是否占用 check */
            ....
            goto ok;
        }
        .......
ok:
        hint += i;
        ......
}

看下面那段代码，如果始终没有端口号可用的话，则须要循环 remaining 次能力宣告端口号耗尽，也就是 28232 次。而如果依照失常的状况，因为有 hint 的存在，所以每次搜寻从下一个待调配的端口号开始计算，以个位数的搜寻就能找到端口号。如下图所示:

所以当端口号耗尽后，Nginx 的 Worker 过程就沉迷在上述 for 循环中不可自拔，把 CPU 吃满。

为什么 Gateway1 调用 Nginx 没有问题

很简略，因为笔者在 Gateway1 调用 Nginx 的时候设置了 Keepalived，所以采纳的是长连贯，就没有这个端口号耗尽的限度。

Nginx 前面有多台机器的话

因为是因为端口号搜寻导致 CPU 100%, 而且凡是有可用端口号，因为 hint 的起因，搜寻次数可能就是 1 和 28232 的区别。

因为端口号限度是针对某个特定的远端 server:port 的。
所以，只有 Nginx 的 Backend 有多台机器，甚至同一个机器上的多个不同端口号，只有不超过临界点，Nginx 就不会有任何压力。

把端口号范畴调大

比拟无脑的计划当然是把端口号范畴调大，这样就能抗更多的 TIME_WAIT。同时将 tcp_max_tw_bucket 调小，tcp_max_tw_bucket 是 kernel 中最多存在的 TIME_WAIT 数量，只有 port 范畴 – tcp_max_tw_bucket 大于肯定的值，那么就始终有 port 端口可用，这样就能够防止再次到调大临界值得时候持续击穿临界点。

cat /proc/sys/net/ipv4/ip_local_port_range
22768    61000
cat /proc/sys/net/ipv4/tcp_max_tw_buckets
20000

开启 tcp_tw_reuse

这个问题 Linux 其实早就有了解决方案，那就是 tcp_tw_reuse 这个参数。

echo '1' > /proc/sys/net/ipv4/tcp_tw_reuse

事实上 TIME_WAIT 过多的起因是其回收工夫居然须要 1min，这个 1min 其实是 TCP 协定中规定的 2MSL 工夫，而 Linux 中就固定为 1min。

#define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy TIME-WAIT
                  * state, about 60 seconds    */

2MSL 的起因就是排除网络上还残留的包对新的同样的五元组的 Socket 产生影响，也就是说在 2MSL(1min)之内重用这个五元组会有危险。为了解决这个问题，Linux 就采取了一些列措施避免这样的状况，使得在大部分状况下 1s 之内的 TIME_WAIT 就能够重用。上面这段代码，就是检测此 TIME_WAIT 是否重用。

__inet_hash_connect
    |->__inet_check_established
static int __inet_check_established(......)
{
    ......    
    /* Check TIME-WAIT sockets first. */
    sk_nulls_for_each(sk2, node, &head->twchain) {tw = inet_twsk(sk2);
        // 如果在 time_wait 中找到一个 match 的 port, 就判断是否可重用
        if (INET_TW_MATCH(sk2, net, hash, acookie,
                    saddr, daddr, ports, dif)) {if (twsk_unique(sk, sk2, twp))
                goto unique;
            else
                goto not_unique;
        }
    }
    ......
}

而其中的外围函数就是 twsk_unique，它的判断逻辑如下:

int tcp_twsk_unique(......)
{
    ......
    if (tcptw->tw_ts_recent_stamp &&
        (twp == NULL || (sysctl_tcp_tw_reuse &&
                 get_seconds() - tcptw->tw_ts_recent_stamp > 1))) {
       // 对 write_seq 设置为 snd_nxt+65536+2
       // 这样可能确保在数据传输速率 <=80Mbit/ s 的状况下不会被回绕      
        tp->write_seq = tcptw->tw_snd_nxt + 65535 + 2
        ......
        return 1;
    }
    return 0;    
}

下面这段代码逻辑如下所示:

在开启了 tcp_timestamp 以及 tcp_tw_reuse 的状况下, 在 Connect 搜寻 port 时只有比之前用这个 port 的 TIME_WAIT 状态的 Socket 记录的最近工夫戳 >1s, 就能够重用此 port, 行将之前的 1 分钟缩短到 1s。同时为了避免潜在的序列号抵触，间接将 write_seq 加上在 65537, 这样，在单 Socket 传输速率小于 80Mbit/ s 的状况下，不会造成序列号重叠 (抵触)。
同时这个 tw_ts_recent_stamp 设置的机会如下图所示:

所以如果 Socket 进入 TIME_WAIT 状态后，如果始终有对应的包发过来，那么会影响此 TIME_WAIT 对应的 port 是否可用的工夫。
开启了这个参数之后, 因为从 1min 缩短到 1s, 那么 Nginx 单台对单 Upstream 可接受的 TPS 就从原来的 470.5TPS(28232/60)一跃晋升为 28232TPS，增长了 60 倍。
如果还嫌性能不够，能够配上下面的端口号范畴调大以及 tcp_max_tw_bucket 调小持续晋升 tps, 不过 tcp_max_tw_bucket 调小可能会有序列号重叠的危险，毕竟 Socket 不通过 2MSL 阶段就被重用了。

不要开启 tcp_tw_recycle

开启 tcp_tw_recyle 这个参数会在 NAT 环境下造成很大的影响，倡议不开启，具体见笔者的另一篇博客:

https://my.oschina.net/alchemystar/blog/3119992

Nginx upstream 改成长连贯

事实上，下面的一系列问题都是因为 Nginx 对 Backend 是短连贯导致。
Nginx 从 1.1.4 开始，实现了对后端机器的长连贯反对性能。在 Upstream 中这样配置能够开启长连贯的性能:

upstream backend {
    server 127.0.0.1:8080;
# It should be particularly noted that the keepalive directive does not limit the total number of connections to upstream servers that an nginx worker             process can open. The connections parameter should be set to a number small enough to let upstream servers process new incoming connections as     well.
    keepalive 32; 
    keepalive_timeout 30s; # 设置后端连贯的最大 idle 工夫为 30s
}

这样前端和后端都是长连贯，大家又能够欢快的游玩了。

由此产生的危险点

因为对单个远端 ip:port 耗尽会导致 CPU 吃满这种景象。所以在 Nginx 在配置 Upstream 时候须要分外小心。假如一种状况，PE 扩容了一台 Nginx, 为避免有问题，就先配一台 Backend 看看状况，这时候如果量比拟大的话击穿临界点就会造成大量报错(而利用自身确毫无压力，毕竟临界值是 470.5TPS(28232/60))，甚至在同 Nginx 上的非此域名的申请也会因为 CPU 被耗尽而得不到响应。多配几台 Backend/ 开启 tcp_tw_reuse 或者是不错的抉择。

总结

利用再弱小也还是承载在内核之上，始终逃不出 Linux 内核的樊笼。所以对于 Linux 内核自身参数的调优还是十分有意义的。如果读过一些内核源码，无疑对咱们排查线上问题有着很大的助力，同时也能领导咱们避过一些坑！

公众号

关注笔者公众号，获取更多干货文章: