正式なドキュメントは英語版であり、この日本語訳はAI支援翻訳により作成された参考用のものです。日本語訳の一部の内容は人間によるレビューがまだ行われていないため、翻訳のタイミングにより英語版との間に差異が生じることがあります。最新かつ正確な情報については、英語版をご参照ください。

PostgreSQLを調整する

  • プラン: Free、Premium、Ultimate
  • 提供形態: GitLab Self-Managed

PostgreSQLを調整する必要がある場合:

  • 他のGitLabコンポーネントが再構成されたり、データベースに影響を与える方法でスケールアップされたりした場合。
  • GitLab環境のパフォーマンスが低下している。
  • GitLabが外部PostgreSQLサービスを使用している。

GitLabに必要な必要なPostgreSQL設定と組み合わせて、この情報を使用してください。

データベース接続を計画する

GitLabのバージョン16.0以降では、mainテーブルとciテーブル用に2組のデータベース接続を使用します。これにより、同じPostgreSQLデータベースが両方のテーブルセットを提供している場合でも、接続の使用量が2倍になります。

GitLabは、複数のコンポーネントからのデータベース接続を使用します。適切な接続計画により、データベース接続の枯渇やパフォーマンスの問題を防ぐことができます。

各GitLabコンポーネントは、その設定に基づいてデータベース接続を使用します。SidekiqとPumaは、初期化時にPostgreSQLへのプール接続を確立します。プール内の接続数は、接続スパイクが発生した場合、または需要が一時的に増加した場合に後で増加する可能性があります:

  • 環境変数DB_POOL_HEADROOMを使用して、データベースプールのヘッドルームを構成します。
  • PostgreSQLを調整する際は、プールのヘッドルームを計画しますが、変更はしないでください。より多くの容量を利用できる場合、GitLabデプロイはより高い要求に対応します。SidekiqまたはPumaのワーカーをさらにデプロイします。

Puma

Puma connections = puma['worker_processes'] × (puma['max_threads'] + DB_POOL_HEADROOM)

デフォルトでは次のようになります:

  • puma['worker_processes']は仮想CPUコア数に基づいています。
  • puma['max_threads']4に等しい。
  • DB_POOL_HEADROOM10に等しい。

ワーカーごとの計算: 各Pumaワーカーは、4つのスレッド + 10のヘッドルームを使用し、合計14の接続になります。

8つの仮想CPUを想定したデフォルト計算: 8ワーカー × ワーカーあたり14接続で、合計112のPuma接続になります。

Sidekiq

Sidekiq connections = Number of Sidekiq processes × (sidekiq['concurrency'] + 1 + DB_POOL_HEADROOM)

デフォルトでは次のようになります:

  • Sidekiqプロセスの数は1です。
  • sidekiq['concurrency']20に等しい。
  • DB_POOL_HEADROOM10に等しい。

デフォルト計算: 1つのSidekiqプロセス × (20並行処理 + 1 + 10ヘッドルーム) で、合計31のSidekiq接続になります。

Geoログカーソル(Geoインストールのみ)

Geoログカーソルデーモンは、セカンダリサイト内のすべてのGitLab Railsノードで実行されます。

Geo log cursor connections = 1 + DB_POOL_HEADROOM

デフォルト計算: 1 + 10ヘッドルームで、合計11のGeo接続になります。

総接続要件

単一ノードインストールの場合:

Total connections = 2 × (Puma + Sidekiq + Geo)

マルチノードインストールの場合、各コンポーネントを実行しているノードの数を掛けます:

Total connections = 2 × ((Puma × Rails nodes) + (Sidekiq × Sidekiq nodes) + (Geo × secondary Rails nodes))

2を掛けることは、GitLab 16.0以降のデュアルデータベース接続を考慮に入れています。

Geoインストールの場合:

  • プライマリサイト: Geo = 0を使用してください。Geoログカーソルは、プライマリサイトでは実行されません。
  • セカンダリサイト: 1つのセカンダリサイトのGeoログカーソルのデータベース接続を計算し、同じ計算をすべてのセカンダリサイトに適用します。
  • 各Geoサイトは独自のデータベースに接続するため、複数のGeoサイト間で接続を合計する必要はありません。
  • max_connectionsを、プライマリPostgreSQLデータベースとすべてのレプリカデータベースの両方で同じ値に設定し、すべてのGeoサイトで最も高い接続要件を使用します。

単一ノードインストール

この例は、20 RPS (1秒あたりのリクエスト数) または1000ユーザーのGitLabリファレンスアーキテクチャに基づいています:

コンポーネントノード設定コンポーネントごとの接続数コンポーネントの合計、デュアルデータベース
Puma18ワーカー、各4スレッドワーカーあたり14224
Sidekiq11プロセス、20並行処理プロセスあたり3162
合計286

マルチノードインストール

この例は、40 RPS (1秒あたりのリクエスト数) または2000ユーザーのGitLabリファレンスアーキテクチャに基づいています:

コンポーネントノード設定コンポーネントごとの接続数コンポーネントの合計、デュアルデータベース
Puma2ノードあたり8ワーカー、各4スレッドワーカーあたり14448
Sidekiq14プロセス、各20並行処理プロセスあたり31248
合計696

Geoを使用した単一ノードインストール

この例は、20 RPS (1秒あたりのリクエスト数) または1000ユーザーのGitLabリファレンスアーキテクチャに基づいています。

Geoサイトごとのコンポーネントノード設定コンポーネントごとの接続数コンポーネントの合計、デュアルデータベース
Puma18ワーカー、各4スレッドワーカーあたり14224
Sidekiq11プロセス、20並行処理プロセスあたり3162
Geoログカーソル(セカンダリサイトのみ)11プロセスプロセスあたり1122
合計308

Geoを使用したマルチノードインストール

この例は、40 RPS (1秒あたりのリクエスト数) または2000ユーザーのGitLabリファレンスアーキテクチャに基づいています:

Geoサイトごとのコンポーネントノード設定コンポーネントごとの接続数コンポーネントの合計、デュアルデータベース
Puma2ノードあたり8ワーカー、各4スレッドワーカーあたり14448
Sidekiq14プロセス、各20並行処理プロセスあたり31248
Geoログカーソル(セカンダリサイトのみ)2Railsノードごとに1つのプロセスプロセスあたり1144
合計740