什么是 Python GIL，它是如何工作的，以及它如何影響 gunicorn。

生產環境我應該選擇哪種 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 不是問題。