プーマへの移籍

GitLab 12.9から、Unicornに代わってPumaがデフォルトのウェブサーバーとして採用されました。 GitLab 13.0からは、明示的に設定しない限り、Unicornの代わりにPumaが実行されます：

  • オールインワンのパッケージベースのインストール。
  • Helmチャートベースのインストール。

プーマに乗り換える理由は？

Pumaはマルチスレッドアーキテクチャを採用しているため、Unicornのようなマルチプロセスのアプリケーションサーバーよりもメモリ消費量が少なくて済みます。 GitLab.comでは、メモリ消費量が40%削減されました。

ほとんどのRailsアプリケーションのリクエストには通常、I/O待ち時間が含まれます。 I/O待ち時間の間、RubyはGVL (Global VM Lock) を他のスレッドに解放します。 そのため、マルチスレッドのPumaは単一プロセスよりも多くのリクエストに対応することができます。

Unicornに代わるPumaの設定

GitLab 13.0から、Pumaがデフォルトのアプリケーションサーバーとなりました。 GitLab 14.0では、Unicornのサポートを削除する予定です。

Puma に切り替えた場合、2 つのアプリケーション・サーバの違いにより、Unicorn サーバの設定は自動的に引き継が_れません_。 Omnibus ベースのデプロイについては、「Puma 設定の構成」を参照してください。 Helm ベースのデプロイについては、「Webservice Chart」のドキュメントを参照してください。

さらに、UnicornとPumaではサービスの再起動時に接続を処理する方法が異なるため、複数ノードのデプロイではロードバランサーを構成して準備チェックを利用することを強くお勧めします。

RuggedでPumaを使用する際のパフォーマンス上の注意点

Git リポジトリの保存に NFS が使用されているデプロイでは、Ruggedを使用してパフォーマンスを向上させるために GitLab がGit に直接アクセスできるようにしています。

Ruggedの使用は、機能フラグによって無効化されていない限り、Gitへの直接アクセスが可能であれば自動的に有効になります。

MRI Ruby は GVL を使用しています。 これにより、MRI Ruby はマルチスレッド化されますが、最大でもシングルコアで動作します。 Rugged は（Git アクセスの集中的な I/O オペレーションのために）スレッドを長時間使用する可能性があるため、リクエストを処理しているかもしれない他のスレッドが飢餓状態になる可能性があります。 Unicorn や Puma がシングルスレッドモードで動作している場合は、同時に最大でも 1 つのリクエストが処理されるため、このようなことは起こりません。

私たちはRuggedの使用廃止に積極的に取り組んでいます。 今日、Ruggedなしでも性能は問題ありませんが、場合によってはRuggedを使用した方が有益なこともあります。

マルチスレッドのPumaでRuggedを実行する際の注意点、およびGitalyの許容可能なパフォーマンスを考慮し、Pumaのマルチスレッドが使用されている場合（Pumaが複数のスレッドで実行されるように設定されている場合）、Ruggedの使用を無効にしています。

デプロイにおいてRuggedが重要な役割を果たす場合は、ベンチマークを実施して最適な設定を確認することをお勧めします：

  • 最も安全な選択肢は、シングルスレッドのPumaから始めることです。 Ruggedで作業する場合、シングルスレッドのPumaはUnicornと同じように動作します。

  • マルチスレッドのPumaでRugged自動検出を強制するには、機能フラグを使用します。