日常Bug排查-连接突然全部关闭 前言 日常Bug排查系列都是一些简单Bug的排查。笔者将在这里介绍一些排查Bug的简单技巧，同时顺便积累素材。 Bug现场 最近碰到一个问题，一台机器上的连接数在达到一定连接数(大概4.5W)连接数之后会突然急速下降到几百。在应用上的表现就是大量的连接报错，系统失去
日常Bug排查系列将介绍一些排查Bug的简单技巧，并积累相关素材。
最近遇到一个问题，一台机器上的连接数在达到一定数量（大约4.5W）后，突然急速下降到几百。这导致大量连接报错，系统失去响应。
笔者首先怀疑代码问题，但经过检查后发现使用的是成熟的框架，代码问题较小。接着怀疑是内核的限制，例如文件描述符到顶了之类，但这又有一个矛盾点。一旦是内核对连接数量限制的话，应该是连接数到达一定程度就涨不上去，而不是连接数跳水式下降。
进一步怀疑是某个间接资源的限制导致到达瓶颈后，所有的连接获取这个资源获取不到而导致全部报错。结合TCP连接消耗的资源无非就是CPU/内存/带宽。
有了上述思路，我们观察相关监控信息。CPU消耗很高，带宽利用率达到了50%，内存使用了大量的内存，但系统的资源消耗还称不上达到瓶颈。
当传统的监控已经不足以分析问题时，笔者使用了针对TCP问题最有效的统计命令，即netstat -s。在这条命令的输出中，发现了一个很不寻常的地方：TCP ran low on memory 19 times。这个输出和笔者对于内存限制的猜想完全对应起来了。
因为之前详细阅读过Linux TCP的源代码以及其所有的可调整的内核参数，所以对TCP的内存限制有映像。有了GPT之后，只需要知道一个大致的方向就好了，直接问GPT就给出了答案，就是tcp_mem这个参数。
在经过响应的内核调整之后，系统的连接数超过了5W之后依旧保持稳定。这时候我们观察相关的TCP消耗内存页的输出。
在此记录下对应的Linux内核栈。可以看到当allocated大于相关的内存limit之后Linux Kernel会将此TCP连接直接Drop。
笔者在了解清楚Bug现场之后，大概花了20分钟就定位到了是TCP内存瓶颈的问题，然后借助GPT非常快速的找到了相关解决方案。不得不说GPT能够大幅加速我们搜索的过程，笔者个人感觉可以在很大程度上替代搜索引擎。但喂给GPT的Prompt还是需要通过Bug现场以及一定的经验来构造，它代替不了你的思考，但能大幅加速信息的检索。
