前言

事实证明，读过Linux内核源码确实有很大的好处，尤其在处理问题的时刻。当你看到报错的那一瞬间，就能把现象/原因/以及解决方案一股脑的在脑中闪现。甚至一些边边角角的现象都能很快的反应过来是为何。笔者读过一些Linux TCP协议栈的源码，就在解决下面这个问题的时候有一种非常流畅的感觉。本文由甜梦文库网m.tmwku.com摘自开源中国

Bug现场

首先，这个问题其实并不难解决，但是这个问题引发的现象倒是挺有意思。先描述一下现象吧， 笔者要对自研的dubbo协议隧道网关进行压测(这个网关的设计也挺有意思，准备放到后面的博客里面)。

那么，就先看看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的存在，所以每次搜索从下一个待分配的端口号开始计算，以个位数的搜索就能找到端口号。m.tmwku.com