Switching to Puma

原文：https://docs.gitlab.com/ee/administration/operations/puma.html

Switching to Puma

从 GitLab 12.9 开始， Puma取代了Unicorn . 作为默认的 Web 服务器. 在 GitLab 13.0 中，除非明确配置为不运行，否则以下命令将运行 Puma 而不是 Unicorn：

  • 基于软件包的多合一安装.
  • 基于舵图的安装.

Why switch to Puma?

Puma 具有多线程体系结构，与像 Unicorn 这样的多进程应用程序服务器相比，它使用的内存更少. 在 GitLab.com 上，我们发现内存消耗减少了 40％.

大多数 Rails 应用程序请求通常都包含一定比例的 I / O 等待时间. 在 I / O 等待时间内，MRI Ruby 将释放 GVL（全局 VM 锁定）到其他线程. 因此，多线程 Puma 仍然可以处理比单个进程更多的请求.

Configuring Puma to replace Unicorn

从 GitLab 13.0 开始，Puma 是默认的应用程序服务器. 我们计划在 GitLab 14.0 中删除对 Unicorn 的支持.

切换到 Puma 时，由于两个应用程序服务器之间的差异，Unicorn 服务器配置将不会自动继承. 对于基于 Omnibus 的部署，请参阅” 配置 Puma 设置” . 对于基于 Helm 的部署，请参阅Webservice Chart 文档 .

此外，由于 Unicorn 和 Puma 在重新启动服务期间如何处理连接方面存在差异，因此我们强烈建议多节点部署将其负载平衡器配置为利用就绪检查 .

Performance caveat when using Puma with Rugged

对于使用 NFS 存储 Git 存储库的部署，我们允许 GitLab 使用直接 Git 访问来使用Rugged来提高性能.

坚固耐用的使用，将自动启用，如果直接 Git 的访问可用 ，除非它被禁用的功能标志 .

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 自动检测，可以使用功能标志 .