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

bug · 浏览次数 : 0

小编点评

**日常Bug排查-连接突然全部关闭前言** **Bug现象：** 一台机器上的连接数在达到一定连接数(大概4.5W)连接数之后会突然急速下降到几百。在应用上的表现就是大量的连接报错，系统失去响应，如下图所示: ``` # 网络连接状态 tcp_stats: estab_sock: 0 in_use: 1024 idle: 0 out_of_use: 0 errors: 1024 dropped: 1024 ``` **分析：** 1. **内存限制：** 在连接数达到瓶颈时，TCP连接申请了大量内存，超过了内核可申请的阈值(3144050)。由于内存紧张，内核无法处理新的连接请求，导致连接数下降。 2. **TCP连接消耗内存：** 每个TCP连接占用大量内存，当连接数超过瓶颈时，每个连接都申请了更多的内存，导致内存紧张。 3. **TCP内存不足：** 当内存不足时，TCP连接会申请更多内存，但内核已达到最大可申请的阈值。当连接数达到瓶颈时，内核会强制关闭连接，导致整个系统连接关闭。 **解决方案：** 1. **调整tcp_mem参数：** 通过修改内核参数`tcp_mem`，可以调整内存申请策略。设置一个更大的`tcp_mem`值可以让内核允许更多内存申请，从而避免内存限制。 2. **监控内存使用：** 使用命令 `netstat -s` 可以监控系统的内存使用情况，观察`tcp_mem`的值变化。如果内存使用超过阈值，可以考虑调整`tcp_mem`参数。 3. **清理连接：** 在连接数下降后，可以清理掉已经关闭的连接，释放系统资源。可以使用命令 `netstat -s | grep -i "tcp_drop"` 来检查已关闭的连接数量。 4. **升级内核：** 如果内核版本低版本，可能存在内存限制问题。升级内核可以解决这个问题。 **提示：** * 可以使用 `cat /proc/sys/net/ipv4/tcp_mem1570347` 命令查看`tcp_mem`参数的值。 * 可以使用 `netstat -s | grep -i "tcp_drop"` 命令检查已关闭的连接数量。 * 可以使用 `cat /proc/sys/net/ipv4/tcp_mem3570347` 命令查看当系统稳定后`tcp_mem`的值。

正文

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