gateworker 分布式部署延遲好幾分鐘
問題描述
這里寫描述
gateworker 分布式部署延遲好幾分鐘
register 和 gateworker mysql 一臺服務(wù)器簡稱A ，businessworker 單獨一臺 簡稱B，目前
B onmesseage 接受到消息比客戶端發(fā)送的消息晚了好幾分鐘
[ 2023-11-11T17:31:58+08:00 ][ log ] 請求參數(shù)：{"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服務(wù)器cpu 60% B服務(wù)器 cpu 20% 這是什么原因呢
其中A服務(wù)器啟動的start_register 和 start_gateway 目前調(diào)的 start_gateway 進(jìn)程是8個
B服務(wù)器啟動的是 start_business 進(jìn)程是128 個
A 服務(wù)的status
B服務(wù)器status
3個回答
還是說很少用戶發(fā)送消息到達(dá)businessworker 都會延遲幾分鐘？ 這樣的話，就檢查下網(wǎng)絡(luò)環(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 現(xiàn)在A服務(wù)一直報這個
-
-
-
latin 2023-11-12請求量太大，服務(wù)端處理不過來了，導(dǎo)致延遲。
你們多少客戶端在線啊，每秒心跳5000個，30秒一個心跳的話，都要15萬在線了。
感覺是客戶端一直在瘋狂發(fā)請求請求量太大導(dǎo)致 -
-
-
-
-
latin 2023-11-12
客戶端1000個，心跳每秒5000個，說明客戶端邏輯有問題，一直在瘋狂發(fā)心跳請求，甚至業(yè)務(wù)請求也在瘋狂發(fā)，業(yè)務(wù)處理不過來。你發(fā)的報錯里的url地址里已經(jīng)說明了原因了
-
-
-
-
-
-
-
-
-
latin 2023-11-12
業(yè)務(wù)有IO請求，比如數(shù)據(jù)庫，curl這些等IO等待的時候不占用本地cpu的。比如一個SQL請求耗時0.5秒，一個進(jìn)程一秒鐘只能處理2個請求。128個進(jìn)程每秒只能處理256個請求，如果每秒有300個請求過來，請求就處理不過來了。但是你會發(fā)現(xiàn)cpu負(fù)載很低，因為大部分都在等待IO返回，不耗費cpu。內(nèi)存夠的你可以開512個進(jìn)程，增加吞吐量。但是也不一定能處理得過來。你最好記錄日志，每個請求處理耗時，每秒處理多少請求。
