複数のSidekiqプロセスを実行する

GitLabは、単一のインスタンスで複数のSidekiqプロセスを開始し、バックグラウンドジョブをより高いレートで処理できます。デフォルトでは、Sidekiqは1つのワーカープロセスを開始し、1つのコアのみを使用します。

複数のプロセスを開始する

複数のプロセスを開始する場合、プロセスの数は、Sidekiqに割り当てるCPUコアの数と最大で等しく（そしてnot超える）なければなりません。Sidekiqワーカープロセスは、CPUコアを1つしか使用しません。

複数のプロセスを開始するには、sidekiq-clusterを使用して作成するプロセスの数と、それらが処理するキューを指定するために、sidekiq['queue_groups']配列設定を使用します。配列内の各項目は、追加のSidekiqプロセス1つに相当し、各項目内の値は、それが動作するキューを決定します。ほとんどの場合、すべてのプロセスはすべてのキューをリッスンする必要があります（詳細については、特定のジョブクラスの処理を参照してください）。

たとえば、利用可能なすべてのキューをリッスンする4つのSidekiqプロセスを作成するには、次の手順を実行します:

1. /etc/gitlab/gitlab.rbを編集します:

   sidekiq['queue_groups'] = ['*'] * 4

2. ファイルを保存して、GitLabを再設定します:

   sudo gitlab-ctl reconfigure

GitLabでSidekiqプロセスを表示するには:

1. 右上隅で、管理者を選択します。
2. モニタリング > バックグラウンドジョブを選択します。

並行処理

デフォルトでは、sidekiqの下で定義された各プロセスは、キューの数に1つの予備のスレッドを加えた数のスレッドで起動し、最大50までです。たとえば、すべてのキューを処理するプロセスは、デフォルトで50のスレッドを使用します。

これらのスレッドは単一のRubyプロセス内で実行され、各プロセスは単一のCPUコアのみを使用できます。スレッドの有用性は、データベースクエリやHTTPリクエストなど、待機する外部依存関係があるワークロードに依存します。ほとんどのSidekiqデプロイは、このスレッド化の恩恵を受けます。

データベース接続の計画

Sidekiqプロセスまたは並行処理を増やす前に、PostgreSQLのmax_connections設定に対するデータベース接続の影響を考慮してください。

詳細な接続計画と計算については、PostgreSQLのチューニングページを参照してください。

スレッド数を明示的に管理する

正しい最大スレッド数（並行処理とも呼ばれます）は、ワークロードによって異なります。一般的な値は、CPUバウンドの高いタスクの場合は5から、混合された低優先度のワークロードの場合は15以上です。非専門的なデプロイの場合、妥当な開始範囲は15から25です。

値は、Sidekiqの特定のデプロイが行うワークロードによって異なります。特定のキュー専用のプロセスを持つその他の専門的なデプロイは、並行処理を次のように調整する必要があります:

• 各種類のプロセスのCPU使用率。
• 達成されたスループット。

各スレッドはRedis接続を必要とするため、スレッドを追加するとRedisのレイテンシーが増加し、クライアントのタイムアウトを引き起こす可能性があります。詳細については、Redisに関するSidekiqドキュメントを参照してください。

並行処理フィールドでスレッド数を管理する

GitLab 16.9以降では、concurrencyを設定することで並行処理を設定できます。この値は、各プロセスにこの量の並行処理を明示的に設定します。

たとえば、並行処理を20に設定するには、次の手順を実行します:

1. /etc/gitlab/gitlab.rbを編集します:

   sidekiq['concurrency'] = 20

2. ファイルを保存して、GitLabを再設定します:

   sudo gitlab-ctl reconfigure

チェック間隔の変更

追加のSidekiqプロセスのSidekiqヘルスチェック間隔を変更するには:

1. /etc/gitlab/gitlab.rbを編集します:

   sidekiq['interval'] = 5

   値は任意の整数秒数にできます。

2. ファイルを保存して、GitLabを再設定します:

   sudo gitlab-ctl reconfigure

CLIを使用したトラブルシューティングを行う

デバッグのため、/opt/gitlab/embedded/service/gitlab-rails/bin/sidekiq-clusterコマンドを使用して追加のSidekiqプロセスを開始できます。このコマンドは、次の構文を使用して引数を取ります:

/opt/gitlab/embedded/service/gitlab-rails/bin/sidekiq-cluster [QUEUE,QUEUE,...] [QUEUE, ...]

--dryrun引数を使用すると、実際にコマンドを開始することなく実行されるコマンドを表示できます。

それぞれの引数は、Sidekiqプロセスによって処理されるキューのグループを示します。複数のキューは、スペースではなくカンマで区切ることで、同じプロセスによって処理できます。

キューの代わりに、キューネームスペースも指定でき、これにより、すべてのキュー名を明示的にリストすることなく、そのネームスペース内のすべてのキューをプロセスが自動的にリッスンできます。キューネームスペースの詳細については、GitLab開発ドキュメントのSidekiq開発パートの関連セクションを参照してください。

sidekiq-clusterコマンドをモニタリングする

sidekiq-clusterコマンドは、必要な量のSidekiqプロセスを開始した後も終了しません。代わりに、プロセスは実行を続け、すべてのシグナルを子プロセスに転送します。これにより、個々のプロセスにシグナルを送信する代わりに、sidekiq-clusterプロセスにシグナルを送信することで、すべてのSidekiqプロセスを停止できます。

sidekiq-clusterプロセスがクラッシュするか、SIGKILLを受信した場合、子プロセスは数秒後に自己を終了します。これにより、ゾンビSidekiqプロセスが発生しないようにします。

これにより、sidekiq-clusterを選択したスーパーバイザー（たとえばrunit）に接続することで、プロセスをモニタリングできます。

子プロセスが終了した場合、sidekiq-clusterコマンドは残りのすべてのプロセスに終了を通知し、その後自己を終了します。これにより、sidekiq-clusterが複雑なプロセスのモニタリング/再起動コードを再実装する必要がなくなります。代わりに、スーパーバイザーがsidekiq-clusterプロセスを必要に応じて再起動するようにする必要があります。

PIDファイル

sidekiq-clusterコマンドは、そのPIDをファイルに保存できます。デフォルトではPIDファイルは書き込まれませんが、sidekiq-clusterに--pidfileオプションを渡すことでこれを変更できます。例:

/opt/gitlab/embedded/service/gitlab-rails/bin/sidekiq-cluster --pidfile /var/run/gitlab/sidekiq_cluster.pid process_commit

PIDファイルには、sidekiq-clusterコマンドのPIDが含まれており、開始されたSidekiqプロセスのPIDではないことに注意してください。

環境

Rails環境は、sidekiq-clusterコマンドに--environmentフラグを渡すか、RAILS_ENVを空ではない値に設定することで設定できます。デフォルト値は/opt/gitlab/etc/gitlab-rails/env/RAILS_ENVにあります。