Switching to Puma

Switching to Puma

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

  • 基于舵图的安装.

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

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

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

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

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

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

MRI Ruby 使用 GVL. 这使得 MRI Ruby 可以是多线程的，但最多只能在单个内核上运行. 由于 Rugged 可以长时间使用线程（由于 Git 访问的密集 I / O 操作），因此这可能会使可能正在处理请求的其他线程饿死. 对于在单线程模式下运行的 Unicorn 或 Puma 而言，情况并非如此，因为最多同时处理一个请求.

考虑到使用多线程 Puma 运行 Rugged 的警告，以及 Gitaly 可接受的性能，如果使用 Puma 多线程（当 Puma 配置为使用多个线程运行时），我们将禁用 Rugged 的使用.

在某些情况下，此默认行为可能不是最佳配置. 如果 Rugged 在您的部署中起着重要作用，我们建议您进行基准测试以找到最佳配置：

  • 最安全的选择是从单线程 Puma 开始. 与 Rugged 一起使用时，单线程 Puma 的工作原理与 Unicorn 相同.

  • 要对多线程 Puma 进行 Rugged 自动检测，可以使用 .