celery 線上問題

2021-09-11 22:11:18 字數 1437 閱讀 9651

專案中使用celery 去做非同步化處理。針對不同的訊息佇列都會啟動8個worker去消費。啟動入口是supervisor,拉起django 的指令碼。再由指令碼去拉起所有的消費程序。

線上celery 容器不停的掛死。通過監控可以看到記憶體過一段時間就會到達記憶體配置值。這時候專案跑不動。

htop
m 使用記憶體排序的方式去檢視,這時候檢視到的單個的程序使用的記憶體都在300以內並不是特別多。但是可以看到程序數量特別的多。同時發現了程序數量特別多,不符合我們通過配置拉起的數量。

ps -aux |grep celery| wc -l
以及監控可以看到程序的數量非常高。

首先定位到報錯是rabbitmq 配置有問題,提單解決。

第二步就是進行優化。優化監控處理方式。

使用 python subprocess popen.通過呼叫 subprocess.popen 類。建立並且返回子程序。

先介紹一下相應屬性

pid

p.pid
returncode

p.returncode
返回子程序的狀態, 對應關係

p.poll() 檢查子程序,返回returncode 屬性。

到這裡,就可以實現子程序監控父程序了。

def check_subprocess(typ, process):

if process is none:

return false

ret = process.poll()

if ret is not none:

return false

return true

因為正常的邏輯子程序不應該退出,所以不為none 都要報錯。

那麼怎麼防止同一任務的子程序存在多份呢?兩種做法:

在捕獲false 的時候,主程序遍歷所有子程序,如果存在則kill。

在主程序啟動的時候根據相應規則查詢,然後去kill掉這些程序。

實力** 實現第二種方法:

def kill_origin_worker():

command = "ps aux | grep 'celery worker' | grep -v grep | awk '' | xargs kill"

# print command

process = subprocess.popen(

command,

shell=true,

close_fds=true)

if process.poll() is not none:

exit(-1)

process.wait()

線上問題排查

問題排查方 長期改進建議 由於業務應用 bug 本身或引入第三方庫 環境原因 硬體問題等原因,線上服務出現故障 問題幾乎不可避免。例如,常見的現象包括請求超時 使用者明顯感受到系統發生卡頓等等。作為乙個合格的研發人員 技術人員 不僅要能寫得一手好 掌握如何排查問題技巧也是研發人高階必須掌握的實戰技能...

線上操作與線上問題排查實戰

一 了解機器連線數情況 問題 192.168.88.136的sshd的監聽埠是22,如何統計192.168.88.136的sshd服務各種連線狀態 time wait close wait established 的連線數。netstat an grep 192.168.88.136 22 awk ...

線上操作與線上問題排查實戰

一 了解機器連線數情況 問題 192.168.88.136的sshd的監聽埠是22,如何統計192.168.88.136的sshd服務各種連線狀態 time wait close wait established 的連線數。netstat an grep 192.168.88.136 22 awk ...