一、背景
之前使用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);
五、后记
整理文档的同时就是将解决问题的过程重新复盘一遍，以后解决这种问题的思路就会比较清晰了。
