日常Bug排查-连接突然全部关闭
前言
日常Bug排查系列都是一些简单Bug的排查。笔者将在这里介绍一些排查Bug的简单技巧，同时顺便积累素材。
Bug现场
最近碰到一个问题，一台机器上的连接数在达到一定连接数(大概4.5W)连接数之后会突然急速下降到几百。在应用上的表现就是大量的连接报错，系统失去响应，如下图所示:
思路
思路1: 第一步肯定是怀疑代码写错了，笔者看了下，使用的是成熟的框架，不是自己操作的连接，那么代码的问题应该较小。
思路2：那么笔者就开始怀疑是内核的限制，例如文件描述符到顶了之类，但这又有一个矛盾点。一旦是内核对连接数量限制的话，应该是连接数到达一定程度就涨不上去，而不是连接数跳水式下降。
思路2.1: 进一步，笔者就开始想，很有可能是某个间接资源的限制导致到达这个瓶颈后，所有的连接获取这个资源获取不到而导致全部报错。再结合TCP连接消耗的资源无非就是CPU/内存/带宽。
监控信息
有了上面的思路，我们就可以观察相关监控信息了。
CPU监控：CPU消耗很高达到了将近70%，但获取不到CPU一般只会导致响应变慢，和问题现象不匹配。
带宽监控：带宽利用率达到了50%，这个带宽利用率算不上高。
内存监控：确实使用了大量的内存，RSS达到了26G，但是比起128G的内存而言，这点消耗量显然不可能成为瓶颈。
好了，看了这三个数据之后，就发现系统的资源消耗还称不上达到瓶颈。但是，笔者从一开始就怀疑内存的使用可能触发了某个特殊的瓶颈。因为只有内存资源申请不到之后，TCP连接才有可能直接报错进而Drop连接。
TCP监控信息
当传统的监控已经不足以分析我们问题的时候，笔者就直接掏出针对TCP问题最有效的统计命令了，祭出法宝:
# 这条命令详细的输出了tcp连接的各种统计参数，很多问题都可以通过其输出获得线索
netstat -s
笔者在这条命令的输出中详细的观察TCP以及TCP内存相关的输出项，定睛一看，就发现一个很不寻常的地方:
...
TcpExt:
TCP ran low on memoery 19 times
......
这个输出就和笔者对于内存限制的猜想完全对应起来了。TCP内存不够了，导致读取或者写入数据的时候申请内存失败进而将TCP连接本身给Drop了。
修改内核参数
因为笔者之前详细的阅读过Linux TCP的源代码以及其所有的可调整的内核参数。所以对TCP的内存限制有映像。有了GPT之后，只需要知道一个大致的方向就好了，直接问GPT就给出了答案，就是tcp_mem这个参数。
cat /proc/sys/net/ipv4/tcp_mem
1570347 2097152 3144050
这三个值分别代表了tcp对于内存在不同阈值下的不同使用策略，单位是页，也就是4KB。具体解释可以直接去问GPT，在此就不赘述了。核心就是TCP消耗的内存总量在大于第三个值也就是3144050(12G，占128G内存的9.35%)的时候TCP就开始由于内存申请不到而Drop连接。而对应的应用由于每个请求高达好几M确实会让每个TCP连接消耗大量的内存。
在内存消耗过程中一旦超限，那么TCP连接就会被内核强制Drop，这也解释了为什么基本所有连接在很短的时间内就跳水式Drop，因为他们都在不停申请内存，而达到临界阈值后全部都报错，进而整个系统的所有连接都关闭导致系统失去响应。如下图所示:
知道是这个问题就很简单了，直接将tcp_mem调大即可：
cat /proc/sys/net/ipv4/tcp_mem
3570347 6097152 9144050
调整后系统保持稳定
在经过响应的内核调整之后，系统的连接数超过了5W之后依旧保持稳定。这时候我们观察相关的TCP消耗内存页的输出:
cat /proc/net/sockstat
TCP: inuse xxx orphan xxx tw xxx alloc xxxx mem 4322151
从这个输出我们可以看到系统平稳运行后，其常态使用的内存页数量mem为4322151已经远大于之前的3144050，这也从侧面验证了笔者的判断。
对应的内核栈
在此记录下对应的Linux内核栈
tcp_v4_do_rcv
|->tcp_rcv_established
|->tcp_data_queue
|->tcp_data_queue
|->tcp_try_rmem_schedule
|->sk_rmem_schedule
|->sk_rmem_schedule
|->__sk_mem_raise_allocated
|-> /* Over hard limit. */
if (allocated > sk_prot_mem_limits(sk, 2))
goto suppress_allocation;
|->goto drop:
tcp_drop(sk,skb)
可以看到当allocated大于相关的内存limit之后Linux Kernel会将此TCP连接直接Drop。
总结
笔者在了解清楚Bug现场之后，大概花了20分钟就定位到了是TCP内存瓶颈的问题，然后借助GPT非常快速的找到了相关解决方案。不得不说GPT能够大幅加速我们搜索的过程，笔者个人感觉可以在很大程度上替代搜索引擎。但喂给GPT的Prompt还是需要通过Bug现场以及一定的经验来构造，它代替不了你的思考，但能大幅加速信息的检索。
