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

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

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

複数のプロセスを開始する場合、プロセスの数は、Sidekiqに割り当てるCPUコア数以下にする必要があります（超えることはできません）。Sidekiqワーカープロセスは、1つ以下のCPUコアを使用します。

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

たとえば、4つのSidekiqプロセスを作成し、それぞれが利用可能なすべてのキューをリッスンするようにするには、次の手順に従います:

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

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

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

   sudo gitlab-ctl reconfigure

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

1. 左側のサイドバーの下部で、管理者を選択します。
2. 左側のサイドバーの下部にあるモニタリングを選択し、次にバックグラウンドジョブを選択します。

並行処理

デフォルトでは、sidekiqで定義された各プロセスは、キューの数に等しい数のスレッドと、最大50までの1つのスペアスレッドで開始します。たとえば、すべてのキューを処理するプロセスは、デフォルトで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

コマンドラインを使用して問題を解決する

デバッグの目的で、/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が複雑なプロセスの監視/再起動codeを再実装する必要がなくなります。代わりに、必要な場合はいつでも、スーパーバイザーがsidekiq-clusterプロセスを再起動するようにしてください。

PIDファイル

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

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

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

環境

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