複数のSidekiqプロセスの実行
GitLabでは、1つのインスタンスでバックグラウンドジョブを高速に処理するために、複数のSidekiqプロセスを起動することができます。デフォルトでは、Sidekiqは1つのワーカープロセスを起動し、1つのCoreのみを使用します。
複数プロセスの起動
- GitLab 12.10から導入された、Sidekiqクラスターによる複数プロセスの起動。
- Sidekiqクラスターは12.10でGitLab Freeに移動しました。
- GitLab 13.0でSidekiqクラスターがデフォルトになりました。
複数のプロセスを起動する場合、プロセス数は最大でもSidekiqに割り当てたいCPUコア数と同じ（そしてそれを超えない）必要があります。Sidekiqワーカープロセスが使用するCPUコアは1つまでです。
複数のプロセスを起動するには、sidekiq['queue_groups'] 配列設定を使用して、sidekiq-cluster を使用して作成するプロセス数と、それらが処理するキューを指定します。配列の各項目は、追加のSidekiqプロセスに相当し、各項目の値は、それが動作するキューを決定します。ほとんどの場合、すべてのプロセスはすべてのキューをリッスンする必要があります (詳細については、特定のジョブクラスの処理を参照してください)。
例えば、4つのSidekiqプロセスを作成し、それぞれが利用可能なすべてのキューをリッスンします：
-
/etc/gitlab/gitlab.rbを編集します：sidekiq['queue_groups'] = ['*'] * 4 -
ファイルを保存して GitLab を再設定してください：
sudo gitlab-ctl reconfigure
GitLabでSidekiqプロセスを表示するには：
- 左のサイドバーで、Search を選択するか、次のページに進んでください。
- Admin Areaを選択します。
- 左サイドバーで、[監視] > [バックグラウンドジョブ]を選択します。
同時実行
デフォルトでは、sidekiq で定義された各プロセスは、キューの数に等しいスレッド数から開始され、最大50スレッドまでの予備スレッドが1つ追加されます。例えば、すべてのキューを処理するプロセスは、デフォルトで50スレッドを使用します。
これらのスレッドは単一のRubyプロセス内で実行され、各プロセスは単一のCPU Coreしか使用できません。スレッドの有用性は、データベースクエリやHTTPリクエストのような、待機する外部依存がある作業に依存します。ほとんどのSidekiqデプロイは、このスレッドの恩恵を受けます。
スレッド数を明示的に管理
適切な最大スレッド数（同時実行数とも呼ばれます）は、ワークロードによって異なります。一般的な値は、CPU負荷の高いタスクの5 から、15 優先度の低いタスクが混在する場合は 15それ以上の範囲になります。15 妥当な開始範囲は 15、特殊化されていないデプロイの場合、25 です。
min_concurrency とmax_concurrency を同じ値に設定して、明示的な同時実行を設定することのみを推奨します。この2つの異なる設定は後方互換性の理由から維持されていますが、より予測可能な結果を得るためには同じ値を使用してください。
たとえば、コンカレンシーを20 ：
-
/etc/gitlab/gitlab.rbを編集します：sidekiq['min_concurrency'] = 20 sidekiq['max_concurrency'] = 20 -
ファイルを保存して GitLab を再設定してください：
sudo gitlab-ctl reconfigure
min_concurrency とmax_concurrency は内部で独立しています。min_concurrency を0 に設定すると、制限が無効になります。min_concurrency を明示的に設定しないことは、0に設定することと同じです。
各キューグループに対して、N をキュー数より一つ多く設定します。同時実行数は
-
min_concurrencyもしこれがmax_concurrencyと等しいならば. -
Nmin_concurrencyとmax_concurrencyの間にある場合。 -
max_concurrencyNがこの値を超えている場合。 -
min_concurrencyNがこの値より小さい場合。
min_concurrency がmax_concurrency, より大きい場合は , と等しいものとして扱わ max_concurrencyれます。
値は、Sidekiqの各特定デプロイが行う作業に応じて異なります。特定のキュー専用のプロセスを持つ他の特殊なデプロイでは、同時実行を次のように調整する必要があります：
- 各タイプのプロセスのCPU使用率。
- 達成されたスループット
各スレッドにはRedis接続が必要なため、スレッドを追加するとRedisの待ち時間が長くなり、クライアントのタイムアウトを引き起こす可能性があります。詳細については、Redisに関するSidekiqのドキュメントを参照してください。
チェック間隔の変更
追加SidekiqプロセスのSidekiqヘルスチェック間隔を変更するには、次の手順に従います：
-
/etc/gitlab/gitlab.rbを編集します：sidekiq['interval'] = 5値は任意の整数秒数です。
-
ファイルを保存して GitLab を再設定してください：
sudo gitlab-ctl reconfigure
CLI を使ったトラブルシューティング
/etc/gitlab/gitlab.rb Sidekiqプロセスの設定には/etc/gitlab/gitlab.rb 。問題が発生した場合は、GitLabサポートに連絡してください。コマンドラインは自己責任で使用してください。
デバッグの目的で、/opt/gitlab/embedded/service/gitlab-rails/bin/sidekiq-cluster コマンドを使用して余分なSidekiqプロセスを起動することができます。このコマンドは以下の構文で引数を取ります：
/opt/gitlab/embedded/service/gitlab-rails/bin/sidekiq-cluster [QUEUE,QUEUE,...] [QUEUE, ...]
--dryrun 引数を指定すると、コマンドを実際に起動せずに、実行するコマンドを表示できます。
それぞれの個別の引数は、Sidekiqプロセスによって処理されなければならないキューのグループを示します。スペースではなくカンマで区切ることにより、複数のキューを同じプロセスで処理することができます。
明示的にすべてのキュー名を列挙することなく、その名前空間内のすべてのキューをプロセスが自動的にリッスンするために、キューの代わりにキュー名前空間を指定することもできます。キュー名前空間の詳細については、Sidekiq開発ドキュメントの関連セクションを参照してください。
sidekiq-cluster コマンドの監視
sidekiq-cluster コマンドは、必要な数のSidekiqプロセスを開始しても終了しません。代わりに、プロセスは実行を継続し、子プロセスにシグナルを転送します。これにより、sidekiq-cluster プロセスにシグナルを送信すると、個々のプロセスにシグナルを送信する代わりに、すべてのSidekiqプロセスを停止できます。
sidekiq-cluster プロセスがクラッシュしたり、SIGKILL を受信した場合、子プロセスは数秒後に終了します。これにより、Sidekiqプロセスがゾンビ化することはありません。
これにより、sidekiq-cluster をお好みのスーパーバイザ（runitなど）に接続して、プロセスを監視できます。
子プロセスが終了した場合、sidekiq-cluster コマンドは残りのすべてのプロセスを終了するようにシグナルを送り、その後自分自身を終了させます。これにより、sidekiq-cluster 複雑なプロセス監視/再起動コードを再実装 sidekiq-clusterする必要がなくなります。sidekiq-cluster その代わりに、スーパーバイザが 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にあります。