小明之线上websocket服务异常排查思路

开篇

话说上周小明在跟产品的激烈争辩中, 虽说最终他用一套观察者模式比较好的解决了特定行为发生后频繁变更后续操作的事情, 但处理过程中对同事的感受来说, 并不是那么好。

于是小明暂时脱离业务的开发， 去做一些技术方面的支持, 还没开始可怜的小明又遇到了新的问题。

技术背景

在他们公司的内部有一个 websocket 服务, 用于给在线的用户推送一些消息， 顶峰时期也就两千多左右的实时用户量(相当于两千多个长连接)

这个 websocket 服务是用 golang 开发，由 nginx 做了反向代理

大概的技术架构图:

突发事故

叮叮叮...

对于这种声音小明早已经再熟悉不过了, 下意识大喊了一声: 有情况! , 把周边人吓了一大跳.

问题排查

websocket 服务报警频发, 立刻去线上连接websocket发现 nginx 504 报错 Gateway Time-out

小明虽说开始做 websocket服务 技术支持, 但还没来得及拥有线上的权限, 立即让运维给他开了个账号, 运维警告他, 不要在这个机器上瞎搞，这个还有其他业务也使用着呢.

小明拿到账号, 登陆后噼里啪啦反复clear命令热身后, 一顿操作猛如虎, 找到了nginx错误日志.

nginx error日志

连接 ws 服务超时. 既然 nginx 说是 ws服务 的问题, 那就看看 ws服务 的错误日志吧.

ws服务 错误日志

看看当前打开的文件数

lsof |wc -l
output:
4435

小明定睛一看, 朝着屏幕同事会心一笑, 这个问题马上修复！

查看系统配置的 open files个数

ulimit -a

额。。。这个已经调整为 65535 了, 我们远没有达到这个限制...

小明从兴奋又陷入到了沉思当中...

再次排查

叮叮叮...

查看 ws服务 pid 19246 进程打开了多少文件

lsof -p 19246 | wc -l

查看这个进程的系统限制

cat  /proc/19246/limits

小明看到 Max open fields为1024, 但是通过 ulimit 命令发现已经调到 65535 了啊. 难道没有生效?

重启大法好!

反正已经不能用了, 直接重启下看看.

....小明两眼一黑,顿时短路......

从 soft limit 说起

ulimit -Sn 查看的是软限制

ulimit -Hn 查看的是硬限制

“在 Linux 的系统中对于进程(Process)会有一些限制，这就所谓的 limit，在实际应用中最常见的就是对打开文件 (Open Files) 的限制，在配置 web 服务如 nginx 时就会用到。在 linux 中这些限制是分为软限制(soft limit)和硬限制(hard limit)的。他们的区别就是软限制可以在程序的进程中自行改变(突破限制)，而硬限制则不行(除非程序进程有root权限)

小明想还有这么多限制呢. 那我提高一点不就可以了嘛

配置具体的限制

cat /etc/security/limits.conf

* 表示适用的所有用户, 配置的soft nofile 已经很高了...

小明想: 为什么 push-ws 的进程会限制再 1024 这个数字呢?

再次思考

莫非是应用程序限制了最大或默认文件打开数? 但是并没有发现文档或代码中去做这个限制.

操作系统没有做任何 1024或4096 的限制, 那这个程序被谁限制了...

小明不仅百度、bing还顺着网线爬到中国香港去谷歌.

“有可能是 supervisor 影响着我们的服务.

我们看下 supervisor 影响 max-open-files 的配置:

minfds=1024; #这个是最少系统空闲的文件描述符，低于这个值supervisor将不会启动。
minprocs=200; #最小可用的进程描述符，低于这个值supervisor也将不会正常启动。

具体这两个参数的官方解释:

“The minimum number of file descriptors that must be available before supervisord will start successfully. A call to setrlimit will be made to attempt to raise the soft and hard limits of the supervisord process to satisfy minfds. The hard limit may only be raised if supervisord is run as root. supervisord uses file descriptors liberally, and will enter a failure mode when one cannot be obtained from the OS, so it’s useful to be able to specify a minimum value to ensure it doesn’t run out of them during execution. These limits will be inherited by the managed subprocesses. This option is particularly useful on Solaris, which has a low per-process fd limit by default. “The minimum number of process descriptors that must be available before supervisord will start successfully. A call to setrlimit will be made to attempt to raise the soft and hard limits of the supervisord process to satisfy minprocs. The hard limit may only be raised if supervisord is run as root. supervisord will enter a failure mode when the OS runs out of process descriptors, so it’s useful to ensure that enough process descriptors are available upon supervisord startup.

因为 supervisor 管理的子进程都是通过它进程 fork 的, 所以针对 supervisor 的配置会影响到子进程的系统参数. 当然 root 用户不受此限制, 但在生产环境, 这并不是一个好注意。

这两个参数正好影响着我们当前服务进程的指标

“supervisord中参数minfds和minprocs决定了supervisord进程及其守护的子进程的Max Processes及Max open files，并且这个limit限制不受系统ulimit所影响。

当然对于我们的服务场景, 将系统参数调高即可。

[supervisord]
minfds=65535
minprocs=65535

重启supervisor服务即可...