483.md 3.7 KB
Newer Older
Lab机器人's avatar
readme  
Lab机器人 已提交
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46
# 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) .