大量短连接过多导致的丢包排查

小记

问题

查看监控平台发现某个服务采集不到数据,在Grafana中异常显示为断点。

此异常服务为阿里云灰度一部分流量至腾讯云,监控表现也都集中在腾讯云。

排查思路

  1. 最开始表现为Grafana异常,也就着手与prometheus数据采集,是不是数据没有采集到,发现prometheus并没有异常,因为监控的其它服务并没有采集不到数据指标的情况
  2. 后端报用户访问确实个别存在异常,怀疑服务本身问题,从服务pod cpu/内存,包括pod所在cpu/内存上看,一切正常
  3. 通过监控告警发现通知:NodeHighNumberConntrackEntriesUsed,通过这一现象怀疑节点的连接跟踪异常
  4. 连接节点主机,查看内核消息,mesg -T,异常提示:nf_conntrack: nf_conntrack: table full, dropping packet
  5. 定位故障,大量短连接占用过多连接跟踪表记录,超过内核:net.nf_conntrack_max(连接跟踪最大值)

内核参数介绍

net.nf_conntrack_max:

​ 该值为连接跟踪记录条目数,一般配置大小需根据机器规格定义,因为跟踪记录保存至内存中,记录条数越多,占用内存越大,当不合理配置该值,也会导致节点主机内存超过其限制。

nf_conntrack_tcp_timeout_time_wait:

连接跟踪条目数GC时间,默认的 established 状态的 GC 时间是 423000s(5 天),设置成这么长的 可能原因是:TCP/IP 协议中允许 established 状态的连接无限期不发送任何东西(但仍然活着),为防止 GC 掉这样长时间没流量但实际还活着的连接,就设置一个足够保守的 timeout 时间,如果对自己的网络环境和需求非常清楚,那可以将这个时间调到一个合理的、足够小的值; 如果不是非常确定的话,还是建议保守一些,例如设置 6 个小时

posted @ 2022-11-09 14:55  元气少女郭德纲!!  阅读(158)  评论(0编辑  收藏  举报