内容简介:之前使用websocket服务为H5页面进行实时数据推送,突然有一天产品给我反馈,说该页面的实时刷新功能失效了,于是开始进行排查和处理,并将过程记录下来。这个服务是有监控程序的,每分钟检查一次websocket是否正常,不正常的话会将进程全部杀掉进行重启。当天接到反馈后,我看了下服务,监控程序是正常的,会对websocket进行重启,但每次重启过后不超过30s,websocket的master节点就又挂了。
之前使用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); 复制代码
五、后记
整理文档的同时就是将解决问题的过程重新复盘一遍,以后解决这种问题的思路就会比较清晰了。
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。