gateworker 分布式部署延遲好幾分鐘
問題描述
這里寫描述
gateworker 分布式部署延遲好幾分鐘
register 和 gateworker mysql 一臺服務器簡稱A ，businessworker 單獨一臺 簡稱B，目前
B onmesseage 接受到消息比客戶端發(fā)送的消息晚了好幾分鐘
[ 2023-11-11T17:31:58+08:00 ][ log ] 請求參數：{"command":,"api_version":"","data":{"addr":"","cpuname":"","iflist":[{"ifaddr":"","ifmac":"14:3d:f2:f3:c0:7f","ifname":""}],"last_ts":1699694855,"load":0.19705462455749512,"os":"","policy_ver":0,"port":"","uuid":""},"ts":1699694855}
ts的時間戳是1699694855 2023-11-11 17:27:35 日志接受的時間是 17:31:58 差了4分鐘多， 目前A服務器cpu 60% B服務器 cpu 20% 這是什么原因呢
其中A服務器啟動的start_register 和 start_gateway 目前調的 start_gateway 進程是8個
B服務器啟動的是 start_business 進程是128 個
A 服務的status
B服務器status
3個回答
還是說很少用戶發(fā)送消息到達businessworker 都會延遲幾分鐘？ 這樣的話，就檢查下網絡環(huán)境以及配置文件。
-
-
-
zsslover 2023-11-12
2023-11-12 13:52:08 pid:3218758 SendBufferToWorker fail. May be the send buffer are overflow. See http://doc2.workerman.net/send-buffer-overflow.html 現在A服務一直報這個
-
-
-
latin 2023-11-12請求量太大，服務端處理不過來了，導致延遲。
你們多少客戶端在線啊，每秒心跳5000個，30秒一個心跳的話，都要15萬在線了。
感覺是客戶端一直在瘋狂發(fā)請求請求量太大導致 -
-
-
-
-
latin 2023-11-12
客戶端1000個，心跳每秒5000個，說明客戶端邏輯有問題，一直在瘋狂發(fā)心跳請求，甚至業(yè)務請求也在瘋狂發(fā)，業(yè)務處理不過來。你發(fā)的報錯里的url地址里已經說明了原因了
-
-
-
-
-
-
-
-
-
latin 2023-11-12
業(yè)務有IO請求，比如數據庫，curl這些等IO等待的時候不占用本地cpu的。比如一個SQL請求耗時0.5秒，一個進程一秒鐘只能處理2個請求。128個進程每秒只能處理256個請求，如果每秒有300個請求過來，請求就處理不過來了。但是你會發(fā)現cpu負載很低，因為大部分都在等待IO返回，不耗費cpu。內存夠的你可以開512個進程，增加吞吐量。但是也不一定能處理得過來。你最好記錄日志，每個請求處理耗時，每秒處理多少請求。
