一次生產(chǎn)問題，gateway-worker導致php進程飆升
問題描述
項目是用gateway-worker寫的，共有2000個連接左右。正常情況下設備連接好后進行正常通信，維護業(yè)務邏輯即可。
上周生產(chǎn)環(huán)境突然cpu飆升，導致所有業(yè)務異常，排查發(fā)現(xiàn)注冊指令被頻繁訪問，
設備商反饋設備需要三秒內(nèi)回復，回復不及時會再次注冊。
想問問什么情況下會導致回復不及時，消息處理不完導致阻塞？如何解決？
程序代碼
操作系統(tǒng)及workerman/webman等框架組件具體版本
"workerman/mqtt":1.7
"workerman/workerman": 4.1.17
"workerman/gateway-worker":3.1.18
"workerman/gatewayclient": 3.0.17
10個回答
這種回復不及時 是調(diào)用第三方接口 相應慢嘛？
打賞
設備要求3秒內(nèi)回復注冊消息，如果沒回復則再次注冊。
2000臺設備，如果gateway-worker重啟，會導致2000設備同時發(fā)送注冊請求，如果服務端無法及時在3秒內(nèi)回復，則設備會繼續(xù)發(fā)起注冊請求，如此循環(huán)。
所以這里有個風險，當服務端處理不過來這些注冊消息時，2000設備會不斷發(fā)送請求，那么就會發(fā)生你說的情況。
解決方案：
多開一些businessWorker進程來增加處理速度，例如開到cpu的4-8倍或者更高。
優(yōu)化業(yè)務，減少數(shù)據(jù)庫等調(diào)用，減少不必要的gateway::xxx()接口調(diào)用，加快業(yè)務處理速度。
減少gateway進程可以降低內(nèi)部接口調(diào)用的負載，少于1萬設備gateway進程數(shù)可以設置為1-2。
盡量不要重啟gateway進程。
如果再次發(fā)生了因為不斷發(fā)送注冊請求導致cpu高的問題，可以每隔3秒執(zhí)行 php start.php reload，這樣可以清理請求隊列里過期的注冊請求，快速恢復服務。
最后
如果問題還未解決，請保留現(xiàn)場 php start.php status 和 top 命令的結(jié)果。
從top命令中能看出哪個進程占用cpu高，假設是pid為28658的進程
執(zhí)行 strace -ttp 28658 查看進程的系統(tǒng)調(diào)用，能大概定位出進程為什么cpu高。
請把上面結(jié)果截圖發(fā)到這里來
-
ixlara 2024-12-23
好的 大佬 ，先按你的方案改進試下
還有個疑問，
我們最近重啟過多次gateway。我理解其實每次都是模擬的一次設備重連的過程，一直也沒事。就上周在沒重啟狀態(tài)下設備批量重連。
如果每次BusinessWorker內(nèi)代碼有變更，可以直接殺掉businessWorker進程，達到代碼熱加載，并且不重啟gateway么？ -
-
walkor 2024-12-23
沒重啟大量設備重連可能是因為服務器網(wǎng)絡問題導致全部設備掉線。
也可能是業(yè)務代碼因為調(diào)用什么操作導致阻塞長時間超時，大量設備因為超時重新不斷發(fā)起請求，大量請求積壓。
也可能是其他沒有想到的原因 -
短解方案：
1、workerman加日志
2、壓測
3、根據(jù)壓測數(shù)據(jù)增加businessWorker數(shù)量
其實我覺得發(fā)生這次事故的根本原因還是沒找到的，所以這次只是一個短解方案。
加上了日志，看會不會復現(xiàn)。等復現(xiàn)保留好現(xiàn)場數(shù)據(jù)再分析
- 暫無評論
