BusinessWorker內(nèi)存持續(xù)增長(zhǎng)，直到溢出exit
有幾個(gè)疑問(wèn)，不知道是不是造成內(nèi)存持續(xù)增長(zhǎng)的原因
以下是大致的消息處理流程
在 Events.php 里，每秒發(fā)送數(shù)據(jù)的次數(shù)在3-8次左右，每次發(fā)送的數(shù)據(jù)量不大。
設(shè)備有兩種數(shù)據(jù)處理方式
其中一類(lèi)處理，頻繁的數(shù)據(jù)轉(zhuǎn)發(fā)到組。
另一類(lèi)處理，頻繁的操作redis（出隊(duì)入隊(duì)）、更新session數(shù)據(jù)。
- 條件成立時(shí)
- 創(chuàng)建1-2個(gè)一次性的定時(shí)器，寫(xiě)入數(shù)據(jù)庫(kù)或者發(fā)送郵件
- 寫(xiě)數(shù)據(jù)到數(shù)據(jù)庫(kù)里
- 推送數(shù)據(jù)到組中的隨機(jī)一個(gè)用戶(hù)
不知道是在哪里的代碼有問(wèn)題，memory_limit 已經(jīng)設(shè)置到800M啦
感謝回答的各位！
5個(gè)回答
打賞
@walkor
session數(shù)據(jù)應(yīng)該不會(huì)太大，不知道頻繁的更新session有沒(méi)關(guān)系？
用GlobalData作為替換方案可以嗎？
- 暫無(wú)評(píng)論
我使用TP6 結(jié)合 workerman 開(kāi)啟了websocket 協(xié)議,作為服務(wù)端給客戶(hù)端推送數(shù)據(jù)。
同時(shí)服務(wù)器又作為客戶(hù)端訂閱了火幣網(wǎng)的數(shù)據(jù)作為數(shù)據(jù)源。
轉(zhuǎn)發(fā)數(shù)據(jù)過(guò)程沒(méi)有存儲(chǔ)數(shù)據(jù)，來(lái)多少數(shù)據(jù)轉(zhuǎn)發(fā)多少數(shù)據(jù)。
我分別在三個(gè)服務(wù)器部署了這套腳本。
除了每個(gè)服務(wù)器開(kāi)放的端口不同外，其他代碼一摸一樣。
問(wèn)題是，前兩個(gè)服務(wù)器運(yùn)行很正常，無(wú)論接收多少請(qǐng)求，使用php think xxxx status 查看運(yùn)行狀態(tài) memory 都是維持在8M，然而最后一個(gè)服務(wù)器開(kāi)啟后 memory 隨著total_request 不斷增長(zhǎng)。
如果不限制php.ini memory_limit 的值 內(nèi)存會(huì)一直增長(zhǎng) 直到耗盡 然后會(huì)自動(dòng)重啟 繼續(xù)開(kāi)始增長(zhǎng)，如此往復(fù)。
我覺(jué)得workerman 本身沒(méi)有問(wèn)題. linux系統(tǒng)環(huán)境方面考慮 是否有什么思路可以去排查，求大佬指引方向。
