WebSocket服务挂掉问题记录

一、背景

之前使用websocket服务为H5页面进行实时数据推送，忽然有一天产品给我反馈，说该页面的实时刷新功能失效了，于是开始进行排查和解决，并将过程记录下来。

这个服务是有监控程序的，每分钟检查一次websocket能否正常，不正常的话会将进程一律杀掉进行重启。

当天接到反馈后，我看了下服务，监控程序是正常的，会对websocket进行重启，但每次重启过后不超过30s，websocket的master节点就又挂了。

情况就是这样的，下面进入排查流程。

二、master节点为什么会挂掉？

在官网上有列举以下三种情况会导致无法提供服务：

(1)系统负载过大swoole无法申请到内存而挂掉(2)swoole底层发生段错误(3)Server占用内存过大被内核Kill，或者者被某些程序误杀

但是根据当前环境，并不符合上述情况，所以这个问题暂时还没有找到具体的起因。

三、根据日志报错处理

（1）首先看了下nginx的error.log，发现大量报错：

13247#0: *176909901 connect() failed (111: Connection refused) while connecting to upstream,

看了下nginx配置,可以看出一开始的配置是很小的，所以对几个配置进行增大

worker_processes  1;  //worker角色的进程个数worker_rlimit_nofile 1024;// 更改worker进程的最大打开文件数限制。worker_connections  1024;//每一个worker进程能并发解决（发起）的最大连接数（包含所有连接数）

（2）swoole自带的log日志中也有很多报错：

ERROR   swServer_master_onAccept (ERROR 502): accept() failed. Error: Too many open files[24]

（3）还有在程序启动会输出：

WARN    swServer_start_check: serv->max_conn is exceed the maximum value[1024].

官方解释为啥会出现这个报错,所以说明当前的问题就是由于ulimit -n设置的过低导致的问题：

max_connection最大不得超过操作系统ulimit -n的值，否则会报一条警告信息，并重置为ulimit -n的值

综合（2）（3）可以得出结论就出在这个ulimit -n上面了，之前也修改过这个值但实际上并没有生效。

ulimit -n 指定同一时间最多可打开的文件数vim /etc/security/limits.conf  -------永久修改ulimit -n 1024 -----------------------即时修改，但重启后就无效了

四、后续问题

（1）访问量上来后，发现会出现redis偶尔链接失败的报错，查找起因是由于大量建立链接导致机器上的端口都在使用中，通过调整内核参数处理。

vim /etc/sysctl.conf编辑文件，加入以下内容：net.ipv4.tcp_tw_reuse = 1 //表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；net.ipv4.tcp_tw_recycle = 1 //表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。而后执行/sbin/sysctl -p让参数生效。

（2）订阅redis后，一段时间后会无法收到信息。起因暂时不明，通过添加链接超时捕获异常后重新建立订阅请求处理。

ini_set('default_socket_timeout', 10);

五、后记

整理文档的同时就是将处理问题的过程重新复盘一遍，以后处理这种问题的思路就会比较清晰了。