小明之線上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服務便可...

結局

等等...

你說啥?

我要重啓

你不能

那我怎麼驗證, 怎麼突出個人貢獻

下來再弄吧。。。

好吧。。。

更多精彩內容, 關注公衆號 呆呆熊的技術路: