日常Bug排查-连接突然全部关闭

日常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现场以及一定的经验来构造,它代替不了你的思考,但能大幅加速信息的检索。
.

posted @ 2024-05-13 09:00  无毁的湖光-Al  阅读(2034)  评论(15编辑  收藏  举报