Switching to Puma · Gitlab 中文文檔

# Switching to Puma > 原文：[https://docs.gitlab.com/ee/administration/operations/puma.html](https://docs.gitlab.com/ee/administration/operations/puma.html) * [Why switch to Puma?](#why-switch-to-puma) * [Configuring Puma to replace Unicorn](#configuring-puma-to-replace-unicorn) * [Performance caveat when using Puma with Rugged](#performance-caveat-when-using-puma-with-rugged) # Switching to Puma[](#switching-to-puma "Permalink") 從 GitLab 12.9 開始， [Puma](https://github.com/puma/puma)取代了[Unicorn](https://yhbt.net/unicorn/) . 作為默認的 Web 服務器. 在 GitLab 13.0 中，除非明確配置為不運行，否則以下命令將運行 Puma 而不是 Unicorn： * 基于軟件包的多合一安裝. * 基于舵圖的安裝. ## Why switch to Puma?[](#why-switch-to-puma "Permalink") Puma 具有多線程體系結構，與像 Unicorn 這樣的多進程應用程序服務器相比，它使用的內存更少. 在 GitLab.com 上，我們發現內存消耗減少了 40％. 大多數 Rails 應用程序請求通常都包含一定比例的 I / O 等待時間. 在 I / O 等待時間內，MRI Ruby 將釋放 GVL（全局 VM 鎖定）到其他線程. 因此，多線程 Puma 仍然可以處理比單個進程更多的請求. ## Configuring Puma to replace Unicorn[](#configuring-puma-to-replace-unicorn "Permalink") 從 GitLab 13.0 開始，Puma 是默認的應用程序服務器. 我們計劃在 GitLab 14.0 中刪除對 Unicorn 的支持. 切換到 Puma 時，由于兩個應用程序服務器之間的差異，Unicorn 服務器配置將*不會*自動繼承. 對于基于 Omnibus 的部署，請參閱" [配置 Puma 設置"](https://docs.gitlab.com/omnibus/settings/puma.html) . 對于基于 Helm 的部署，請參閱[Webservice Chart 文檔](https://docs.gitlab.com/charts/charts/gitlab/webservice/index.html) . 此外，由于 Unicorn 和 Puma 在重新啟動服務期間如何處理連接方面存在差異，因此我們強烈建議多節點部署[將其負載平衡器配置為利用就緒檢查](../high_availability/load_balancer.html#readiness-check) . ## Performance caveat when using Puma with Rugged[](#performance-caveat-when-using-puma-with-rugged "Permalink") 對于使用 NFS 存儲 Git 存儲庫的部署，我們允許 GitLab 使用[直接 Git 訪問](../gitaly/index.html#direct-access-to-git-in-gitlab)來使用[Rugged](https://github.com/libgit2/rugged)來提高性能. 堅固耐用的使用，將自動啟用，如果直接 Git 的訪問[可用](../gitaly/index.html#how-it-works) ，除非它被禁用[的功能標志](../../development/gitaly.html#legacy-rugged-code) . MRI Ruby 使用 GVL. 這使得 MRI Ruby 可以是多線程的，但最多只能在單個內核上運行. 由于 Rugged 可以長時間使用線程（由于 Git 訪問的密集 I / O 操作），因此這可能會使可能正在處理請求的其他線程餓死. 對于在單線程模式下運行的 Unicorn 或 Puma 而言，情況并非如此，因為最多同時處理一個請求. 我們正在積極致力于消除 Rugged 的使用. 即使沒有 Rugged 的性能今天已經可以接受，但在某些情況下使用它仍然可能是有益的. 考慮到使用多線程 Puma 運行 Rugged 的警告，以及 Gitaly 可接受的性能，如果使用 Puma 多線程（當 Puma 配置為使用多個線程運行時），我們將禁用 Rugged 的使用. 在某些情況下，此默認行為可能不是最佳配置. 如果 Rugged 在您的部署中起著重要作用，我們建議您進行基準測試以找到最佳配置： * 最安全的選擇是從單線程 Puma 開始. 與 Rugged 一起使用時，單線程 Puma 的工作原理與 Unicorn 相同. * 要對多線程 Puma 進行 Rugged 自動檢測，可以使用[功能標志](../../development/gitaly.html#legacy-rugged-code) .