记录一次 CLOSE_WAIT 问题排查和梳理

环境描述

要说清楚事情,不介绍下背景和环境好像不行啊

背景

  • 公司内部有一套RPC服务框架,java开发的,rpc协议用的redis
  • 我所在的部门没java人手,但夸部门的数据交互又越来越多,一开始用http 接口性能不好,qps到2-3千的时候调用方经常发生各种curl 网络错误,导致拿不到数据,影响很不好
  • 所以后来自己拿 php+swoole 实现RPC服务,延用公司的框架,协议和服务注册啥的都保持一致,就是具体业务用php来实现

数据流转示意图

记录一次 CLOSE_WAIT 问题排查和梳理

  • 绿色那块-中间椭圆的就是这次出问题的服务
  • 我们可能会被PHP-FPM和其他RPC服务请求,也可能请求其他RPC服务和DB, 这样说应该清楚了吧

发现和排查解决

  • 发现:收到zabbix发的报警 PROBLEM: system close_wait [9522>5300], 首次报警
  • 脑子想了下,通常如果出问题都是调用方反馈,这次调用方没反馈应该没影响到具体业务,也没啥其它好确认的,直接上服务器看吧
  • ss -ant | grep CLOSE-WAIT 确认下果然是这样
  • close-wait 具体含义简单说下,看图
  • 记录一次 CLOSE_WAIT 问题排查和梳理
  • 这是tcp的挥手图,当主动关闭的一方发出FIN包,被动方回复ACK后自己就进入CLOSE_WAIT状态,正常情况下,被动方稍后就应该发出FIN包,并确认收到ACK回复,然后连接就可以正常关闭了
  • 很显然由于某些原因,我们的swoole程序(被动方)没能发出FIN包,这个为什么回头再分析,先把报警解决了
  • close_wait 是不会自动消失的,根据上面ss -ant 结果配合 lsof -i :{$port} 查到具体的服务,隔离-重启-恢复这个服务, 当然了ss -ant 的结果要保存下来,等下要分析具体谁跟我断了。。。

原因分析和调整

分析

  • ss -ant 的结果看了下,close_wait 的 Foreign Address 基本都是RPC(java), 很多都是常用服务,整个公司都在用,基本排除是对方的原因
  • 这次有2台机器都出现了问题,但2台机器上引起close_wait的service进程是不一样的,但有个特征就是请求量很少

所以大胆推测对方主动断开的原因是这样的

  • 因为 swoole 不忙,导致建立的socket连接超过了闲置时间,然后对方就觉得timeout了,然后主动断开了
  • 还注意到close_wait 对方很多是按理不应该用到的rpc服务,我猜这个应该是php代码没写好有关系。 看开头的背景也知道,用swoole搭服务时间还是很紧张的,业务逻辑基本都是直接用的http api那套代码,而swoole是常驻内存的,本来某些变量/连接在api那套里面随着请求结束就回收了,但是在swoole里不会

接着在分析下swoole为什么在被动关闭时为什么没发FIN

  • 看了下官方的onClose说明,有说到onClose回调函数如果发生了致命错误,会导致连接泄漏。通过netstat命令会看到大量CLOSE_WAIT状态的TCP连接
  • 我觉得基本就是onClose这里出了问题;我看了下php的error log, 没发现fatal error;
  • 我们4台机器,其中2台发生问题,而且是不同的服务。加上用关键字swoole close wait google 没有发现案例。基本排除是swoole的问题,还是我使用的姿势不对然后有几率导致发生这个问题
  • 然后就没有然后了,这4个机器的服务也跑了一年多了,第一次发生这个情况,我又不懂系统原理和c,加上案发现场现在也关闭了

调整

  • 这2个不活跃的服务配置的worker num 都是96个, 其中一个是同事开发的,使用的默认配置(默认配置是有个配置文件,我弄的,我好像没讲过要调低),另一个一开始请求量多,后来业务下了,也忘了调低
  • 整理了下,请求量低的服务 worker number 都调低

经验总结

  • 系统原理网络c语言 要尽量多学习, 不然承担这种基础架构服务,万一出了底层问题,你就不太能搞的定了,都是只能治标,不能治本
上一篇:GPS定位系统二次开发为什么一定要选择专业的


下一篇:Java内存模型,你有认真了解过吗