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);

五、后记

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

你可能感兴趣的:(WebSocket服务挂掉问题记录)