环境描述
要说清楚事情，不介绍下背景和环境好像不行啊
背景
- 公司内部有一套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 waitgoogle 没有发现案例。基本排除是swoole的问题，还是我使用的姿势不对然后有几率导致发生这个问题 - 然后就没有然后了，这4个机器的服务也跑了一年多了，第一次发生这个情况，我又不懂系统原理和c，加上案发现场现在也关闭了
调整
- 这2个不活跃的服务配置的worker num 都是96个， 其中一个是同事开发的，使用的默认配置（默认配置是有个配置文件，我弄的，我好像没讲过要调低），另一个一开始请求量多，后来业务下了，也忘了调低
- 整理了下，请求量低的服务 worker number 都调低
经验总结
-
系统原理、网络、c语言要尽量多学习， 不然承担这种基础架构服务，万一出了底层问题，你就不太能搞的定了，都是只能治标，不能治本
