一文搞懂 Gunicorn 與 Python GIL

什麼是 Python GIL，它是如何運作的，以及它如何影響 gun​​icorn。

生產環境我該選擇哪一種 Gunicorn worker類型？

Python 有一個全域鎖定 (GIL)，它只允許一個執行緒運行（即解釋字節碼）。在我看來，如果你想優化你的 Python 服務，理解 Python 如何處理並發是必不可少的。

Python 和 gunicorn 為您提供了處理並發的不同方法，並且由於沒有涵蓋所有用例的靈丹妙藥，因此最好了解每個選項的選項、權衡和優勢。

Gunicorn worker類型

Gunicorn 以「workers types」的概念公開了這些不同的選項。每種類型都適用於一組特定的用例。

• sync——將進程分叉成 N 個並行運行的進程來處理請求。
• gthread——產生 N 個執行緒來並發服務請求。
• eventlet/gevent－產生綠色執行緒來並發服務請求。

Gunicorn sync worker

這是最簡單的工作類型，其中唯一的並發選項是分叉N個進程，它們將並行地服務請求。

它們可以很好地工作，但會招致大量開銷(例如記憶體和CPU上下文切換)，而且如果您的大部分請求時間都在等待I/O，那麼伸縮性就不好。

Gunicorn gthread worker

gthread worker 透過讓您為每個流程建立 N 個執行緒來改進這一點。這提高了 I/O 效能，因為您可以同時執行更多程式碼實例。這是受 GIL 影響的四個中唯一一個。

Gunicorn eventlet and gevent workers

eventlet/gevent workers試圖透過執行輕量級使用者執行緒（又稱綠色執行緒、greenlets 等）來進一步改進 gthread 模型。

與系統執行緒相比，這允許您以很少的成本擁有數千個所述的greenlet。  另一個差異是它遵循協作工作模式而不是搶佔式，允許不間斷工作，直到它們阻塞為止。我們將首先分析 gthread 工作執行緒在處理請求時的行為以及它如何受 GIL 影響。

與每個請求直接由一個進程提供服務的sync不同，使用gthread，每個進程都有N 個線程，以便更好地擴展，而無需產生多個進程的開銷。由於您在同一個進程中運行多個線程，GIL 將阻止它們並行運行。

GIL 不是行程或特殊執行緒。它只是一個布林變量，其存取受互斥鎖保護，用於確保每個進程內只有一個執行緒在運行。它的運作方式可以在上圖中看到。在這個例子中，我們可以看到我們有 2 個系統執行緒並發運行，每個執行緒處理 1 個請求。流程是這樣的：

• 執行緒 A 持有 GIL 開始服務請求。
• 過了一會兒，執行緒 B 嘗試提供請求，但無法持有 GIL。
• B 設定逾時以強制釋放 GIL，如果在達到逾時之前不會發生這種情況。
• A 在達到逾時之前不會釋放 GIL。
• B 設定 gil_drop_request 標誌以強制 A 立即釋放 GIL。
• A 釋放 GIL 並將等待直到另一個執行緒抓取 GIL，以避免出現 A 會不斷釋放並抓取 GIL 而其他執行緒無法抓取它的情況。
• B 開始運作。
• B 在阻塞 I/O 的同時釋放 GIL。
• A 開始運行。
• B 嘗試再次運行但被暫停。
• A 在達到逾時之前完成。
• B 跑完畢。

相同的場景，但使用gevent

#在不使用進程的情況下增加並發性的另一個選擇是使用greenlets。該worker產生“用戶線程”而不是“系統線程”以增加並發性。

儘管這意味著它們不受 GIL 的影響，但這也意味著您仍然無法增加並行度，因為它們無法由 CPU 並行調度。

• Greenlet A將開始運行，直到發生I/O事件或執行完畢。
• Greenlet B將等待直到Greenlet A釋放事件循環。
• A結束。
• B開始。
• B釋放事件循環以等待I/O。
• B完成。

對於這種情況，很明顯，擁有一個 greenlet 類型的worker並不理想。我們最終讓第二個請求等到第一個請求完成，然後再次空閒等待 I/O。

在這些場景中，greenlet 協作模型真的很出色，因為您不會在上下文切換上浪費時間並避免運行多個系統執行緒的開銷。

我們將在本文最後的基準測試中見證這一點。 現在，這引出了以下問題：

• 更改執行緒上下文切換超時是否會影響服務延遲和吞吐量？
• 當您混合使用 I/O 和 CPU 工作時，如何在 gevent/eventlet 和 gthread 之間進行選擇。
• 如何使用 gthread worker 選擇執行緒數。
• 我應該只使用sync worker並增加分叉進程的數量來避免 GIL 嗎？

要回答這些問題，您需要進行監控以收集必要的指標，然後針對這些相同的指標執行量身定制的基準測試。執行與您的實際使用模式零相關性的綜合基準測試是沒有用的 下圖顯示了不同場景的延遲和吞吐量指標，讓您了解這一切是如何協同工作的。

對 GIL 切換間隔進行基準測試

在這裡我們可以看到更改 GIL 執行緒切換間隔/逾時如何影響請求延遲。正如預期的那樣，IO 延遲隨著切換間隔的降低而變得更好。發生這種情況是因為受 CPU 限制的執行緒被迫更頻繁地釋放 GIL 並允許其他執行緒完成它們的工作。

但這不是靈丹妙藥。減少切換間隔將使 CPU 綁定執行緒需要更長的時間才能完成。我們也可以看到總延遲增加，由於恆定執行緒切換的開銷增加，超時時間減少。如果您想自己嘗試，可以使用以下程式碼變更切換間隔：

#使用CPU 綁定請求對gthread 與gevent 延遲進行基準測試

#總的來說，我們可以看到基準測試反映了我們先前對GIL 綁定執行緒和greenlet 如何運作的分析所產生的直覺。

由於切換間隔迫使長時間運行的執行緒釋放，gthread 對於 IO 綁定請求具有更好的平均延遲。

gevent CPU 綁定請求比 gthread 具有更好的延遲，因為它們不會中斷以服務其他請求。

使用CPU 綁定請求對gthread 與gevent 吞吐量進行基準測試

這裡的結果也反映了我們之前對gevent 比gthread具有更好吞吐量的直覺。這些基準高度依賴完成的工作類型，不一定直接轉換為您的用例。

這些基準測試的主要目標是為您提供一些有關測試和測量內容的指南，以便最大限度地提高將服務於請求的每個 CPU 核心。

由於所有 gunicorn worker 都允許您指定將運行的進程數，因此更改的是每個進程如何處理並發連接。因此，請確保使用相同數量的worker以使測試公平。現在讓我們嘗試使用從我們的基準測試中收集的數據來回答前面的問題。

更改執行緒上下文切換逾時是否會影響服務延遲和吞吐量？

 #確實如此。然而，對於絕大多數工作負載來說，它並沒有改變遊戲規則。

當您混合使用 I/O 和 CPU 工作時，如何在 gevent/eventlet 和 gthread 之間進行選擇？正如我們所看到的，當您有更多 CPU 密集型工作時，ghtread 往往允許更好的並發性。

如何選擇gthread worker的執行緒數？

只要您的基準測試能夠模擬類似生產的行為，您就會清楚地看到峰值效能，然後它會因線程過多而開始下降。

我應該只使用同步工作者並增加分叉進程的數量來避免 GIL 嗎？

除非您的 I/O 幾乎為零，否則僅使用進程進行擴充並不是最佳選擇。

結論

Coroutines/Greenlets 可以提高 CPU 效率，因為它們避免了執行緒之間的中斷和上下文切換。協程用延遲換取吞吐量。

如果您混合使用 IO 和 CPU 綁定端點，協程可能會導致更難以預測的延遲－CPU 綁定端點不會中斷以服務其他傳入請求。如果您花時間正確配置 gunicorn，GIL 不是問題。

以上是一文搞懂 Gunicorn 與 Python GIL的詳細內容。更多資訊請關注PHP中文網其他相關文章！