如何辨別uWSGI優先進程以進行負載平衡

我已經在具有3個CPU核心的VDS上安裝了Nginx + uWSGI + Django。 uWSGI針對每個進程配置6個進程和5個線程。現在我想告訴uWSGI使用進程進行負載平衡，直到所有進程都忙碌，然後在需要時使用線程。看來uWSGI更喜歡線程，而且我還沒有找到任何配置選項來改變這種行爲。第一個進程佔用100％的CPU時間，第二個佔用大約20％，另外一個進程大多不使用。如何辨別uWSGI優先進程以進行負載平衡

我們的網站收到40 r/s。實際上即使有3個沒有線程的進程通常也足以處理所有的請求。但是由於諸如鎖定共享資源等各種原因，請求處理會不時掛起。在這種情況下，我們有-1進程。用戶不喜歡等待，並一次又一次地點擊鏈接。結果所有進程都掛起，所有用戶都必須等待。

我會添加更多的線程來使服務器更健壯。但問題可能是python GIL。線程不會使用所有的CPU核心。所以多個進程在負載平衡方面效果更好。但是，如果鎖定共享資源和I/O等待延遲，線程可能會有很大幫助。一個進程可能會做很多工作，而其中一個線程被鎖定。

我不想減少時間限制，直到沒有其他解決方案。理論上可以用線程來解決這個問題，我不想向用戶顯示錯誤消息，或者讓他在每個請求中等待，直到沒有其他選擇。

來源

2013-10-07 raacer

所以，解決的辦法是：

升級uWSGI最近的穩定版本（羅伯託建議）。
使用 - 鎖定選項。

現在我運行的每個進程有50個線程，所有請求在進程間平均分配。

來源

2013-10-11 20:05:35 raacer

每個進程都是有效的線程，因爲線程是同一進程的執行上下文。

由於這樣的原因，沒有什麼像「一個進程執行它而不是一個線程」。即使沒有線程，你的進程也有1個執行上下文（一個線程）。我想調查的是爲什麼當你在每個進程中使用多個線程時，你會感覺到糟糕的表現。你確定你正在使用一個穩定的（有穩固的線程支持）的uWSGI版本嗎？（1.4.x或1.9.x）

您是否想過在服務器過載時動態生成更多進程？檢查uWSGI更便宜的模式，有各種可用的算法。也許會適合你的情況。

GIL對你來說不是一個問題，因爲從你所描述的問題來看，缺少用於管理新請求的線程（即使從你的數字看來，你可能在其他事情上有過多的重鎖爭用）

來源

2013-10-08 03:36:18 roberto

當我說「進程而不是線程進行負載平衡」時，我的意思是我想在進程之間平衡線程使用情況，而不是將所有請求都推送到單個進程，除非它100％繁忙。由於GIL，Python中的單個進程中的線程並不是真正的並行。那麼uWSGI 1.4呢？它有更好的負載平衡算法嗎？我使用Ubuntu LTS和uwsgi 1.0.3（希望它在lts中穩定）。更新它有意義嗎？我也考慮過更便宜的模式，但主要是爲了解決雷鳴的牛羣問題。但我並不覺得缺乏線程，大多數都沒有用到。 – raacer

任何<1.4不支持和錯誤。 1.0超過2歲，同時uWSGI進化（和改進）很多。作爲主要的uWSGI作者，我可以說任何<1.4與uWSGI目前的狀況無關。 – roberto

「作爲主要的uWSGI作者」是一個有說服力的論點！你必須從這一開始:)謝謝你的解釋，我很高興收到來自uWSGI作者的答案。也許你可以簡單地解釋一下選擇1.9中的請求處理線程的當前邏輯是什麼？能不能請你？ – raacer

如何辨別uWSGI優先進程以進行負載平衡

回答

相關問題