uWSGI工人被困：爲什麼

我使用uwsgi版本2.0.13.1與以下配置：uWSGI工人被困：爲什麼

bin/uwsgi -M -p 5 -C -A 4 -m -b 8192 -s :3031 --wsgi-file bin/django.wsgi --pidfile var/run/uwsgi.pid --touch-reload=var/run/reload-uwsgi.touch --max-requests=1000 --reload-on-rss=450 --py-tracebacker var/run/pytrace --auto-procname --stats 127.0.0.1:3040 --threads 40 --reload-mercy 600 --listen 200

（絕對路徑名切）

當我運行uwsgitop，所有5名工人出現忙。當我嘗試使用py-tracebacker獲取每個工作者/線程的堆棧跟蹤時，我沒有得到任何答案。進程只是掛起。

我怎麼能研究什麼確切的事實是什麼使uwsgi處理掛？

我該如何預防這種情況？

我知道切腹參數，但我不知道它是否有其他活動線程進程被殺死。

PD：「重裝慈悲」設置爲一個非常高的價值避免工人與仍處於活動狀態的線程殺害（似乎是一個bug）。我們有一些Web請求仍然需要很長時間（這些請求正在轉換爲作業）。

在此先感謝。

來源

2017-06-29 erny

您是否得到了解決方案？ –

是的，請參閱https://github.com/unbit/uwsgi/issues/1599。基本上，在Python 2.7中導入一些stdlib模塊（如日誌記錄）可能不是線程安全的。所以我把這些輸入移到了wsgi模塊本身，這些模塊在uwsgi之前就派生出來了 – erny

雖然我已經添加了一條評論，但這裏有更長的描述。

警告：問題只是站起身使用多個工作流程和一個以上的線程（-p --threads）時。

短版：在Python 2.7.x一些模塊不是進口（日誌記錄，編解碼器的隱含進口）在100％線程安全的。嘗試在uwsgi的wsgi文件中導入所有這些有問題的模塊（即，在uwsgi分支之前）。

長版本：在https://github.com/unbit/uwsgi/issues/1599我分析了這個問題，發現它可能與python bug with the logging module有關。這個問題可以通過導入和初始化uwsgi分支之前的任何關鍵模塊來解決，這些分支在執行給uwsgi的wsgi腳本之後發生。

我終於解決了我的問題settings.ROOT_URLCONF直接或間接地從WSGI文件導入Django的。這也有減少內存消耗的好處（因爲工人之間共享的代碼庫更大）以及每個工作人員的初始化時間。

來源

2018-01-10 16:01:50 erny

uWSGI工人被困：爲什麼

回答

相關問題