环境描述
要说清楚事情,不介绍下背景和环境好像不行啊
背景
- 公司内部有一套RPC服务框架,java开发的,rpc协议用的redis
- 我所在的部门没java人手,但夸部门的数据交互又越来越多,一开始用http 接口性能不好,qps到2-3千的时候调用方经常发生各种curl 网络错误,导致拿不到数据,影响很不好
- 所以后来自己拿 php+swoole 实现RPC服务,延用公司的框架,协议和服务注册啥的都保持一致,就是具体业务用php来实现
数据流转示意图
- 绿色那块-中间椭圆的就是这次出问题的服务
- 我们可能会被PHP-FPM和其他RPC服务请求,也可能请求其他RPC服务和DB, 这样说应该清楚了吧
发现和排查解决
- 发现:收到zabbix发的报警
PROBLEM: system close_wait [9522>5300], 首次报警
- 脑子想了下,通常如果出问题都是调用方反馈,这次调用方没反馈应该没影响到具体业务,也没啥其它好确认的,直接上服务器看吧
-
ss -ant | grep 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语言
要尽量多学习, 不然承担这种基础架构
服务,万一出了底层问题,你就不太能搞的定了,都是只能治标,不能治本