- 利用可能なSidekiqキュー
- 複数のプロセスの開始
- ネガティブ設定
- キューセレクタ(実験的)
- すべての GitHub インポートキューを無視
- スレッド数
- 並行性の管理
- チェック間隔の変更
- CLIを使用したトラブルシューティング
複数のSidekiqプロセスの実行
GitLabでは、複数のSidekiqプロセスを起動することができます。 これらのプロセスは、専用のキューセットを消費するために使用することができます。 これは、処理する必要があるジョブの数に関係なく、特定のキューが常に専用のワーカーを持つようにするために使用することができます。
利用可能なSidekiqキュー
既存のSidekiqキューのリストについては、以下のファイルを確認してください:
上記ファイルの各エントリーは、Sidekiqプロセスを開始できるキューを表します。
複数のプロセスの開始
- GitLab 12.10で導入された、Sidekiqクラスターによる複数プロセスの起動。
- Sidekiq クラスターは GitLab 12.10 で GitLabCoreに移動しました。
- GitLab 13.0でSidekiqクラスターがデフォルトになりました。
複数のプロセスを開始するには
-
sidekiq['queue_groups']
配列設定を使用して、sidekiq-cluster
を使用して作成するプロセスの数と、それらが処理するキューを指定します。 配列の各項目は、追加の Sidekiq プロセス 1 つに相当し、各項目の値は、それが動作するキューを決定します。例えば、以下の設定により、3つのSidekiqプロセスが作成されます。1つは
elastic_indexer
上で実行され、1つはmailers
上で実行され、1つはすべてキュー上で実行されます:sidekiq['queue_groups'] = [ "elastic_indexer", "mailers", "*" ]
追加のSidekiqプロセスに複数のキューを処理させるには、カンマで区切られた複数のキュー名をその項目に追加します。 例えば、以下のようになります:
sidekiq['queue_groups'] = [ "elastic_indexer, elastic_commit_indexer", "mailers", "*" ]
GitLab12.9以降では、特別なキュー名
*
はすべてのキューを意味します。 これは2つのプロセスを起動し、それぞれがすべてのキューを処理します:sidekiq['queue_groups'] = [ "*", "*" ]
*
を具体的なキュー名と組み合わせることはできません -*, mailers
はmailers
のキューだけを扱います。sidekiq-cluster
が単一のノード上でのみ実行されている場合、少なくとも1つのプロセスが*
を使用してすべてのキューで実行されていることを確認してください。 これは、プロセスが将来作成されるキューのジョブを自動的にピックアップすることを意味します。sidekiq-cluster
が複数のノードで実行されている場合、--negate
を使用して、すでに処理されているすべてのキューを一覧表示することもできます。 -
ファイルを保存し、変更を有効にするために GitLab を再設定します:
sudo gitlab-ctl reconfigure
Sidekiqプロセスを追加したら、GitLabの Admin Area > Monitoring > Background Jobs(/admin/background_jobs
) に移動します。
ネガティブ設定
追加Sidekiqプロセスを、リストしたキュー以外のすべてのキューで動作させるには:
-
追加プロセスを開始する手順を踏んだら、
/etc/gitlab/gitlab.rb
を編集して追加します:sidekiq['negate'] = true
-
ファイルを保存し、変更を有効にするために GitLab を再設定します:
sudo gitlab-ctl reconfigure
キューセレクタ(実験的)
GitLab Starter12.8 で導入されました。
上記のような名前によるキュー選択に加えて、experimental_queue_selector
オプションでは、以下のコンポーネントを使用して、より一般的な方法でキューグループを選択することができます:
- 選択できる属性
- クエリの構築に使用されるオペレーション。
利用可能な属性
- GitLab 13.1 で導入された
tags
。
experimental_queue_selector
では、利用可能なすべての属性のリストから、以下の属性によってキューを選択することができます:
-
feature_category
- キューが属するGitLab 機能カテゴリ。例えば、merge
キューはsource_code_management
カテゴリに属します。 -
has_external_dependencies
- 例えば、すべてのインポータはこの設定をtrue
にしています。 -
urgency
- このキューのジョブの迅速な実行の重要度を指定します。指定可能な値はhigh
、low
、あるいはthrottled
です。 例えば、authorized_projects
のキューは、ユーザの権限を更新するために使用され、緊急度が高いものです。 -
name
- 他の属性はより一般的であるため、通常はより有用ですが、特定のキューを選択する必要がある場合に利用できます。 -
resource_boundary
- キューがcpu
、memory
、またはunknown
によって束縛されている場合。 例えば、project_export
のキューは、データをエクスポートするために保存する前にメモリにロードする必要があるため、 メモリ束縛されています。 -
tags
- これらはリリースごとに頻繁に変更されることが予想され、完全に削除される可能性もあります。
has_external_dependencies
はブーリアン属性です。true
の正確な文字列のみが真とみなされ、それ以外は偽とみなされます。
tags
は集合です。つまり、=
は交差する集合をチェックし、!=
は不連続な集合をチェックします。例えば、tags=a,b
は、a
、b
、またはその両方のタグを持つキューを選択します。tags!=a,b
は、これらのタグのどちらも持たないキューを選択します。
利用可能なオペレーション
experimental_queue_selector
は、優先順位の高いものから順に、以下のオペレーションをサポートしています:
-
|
- 例えば、query_a|query_b
(query_a
とquery_b
はここでの他の演算子で構成されるクエリです)は、どちらかのクエリにマッチするキューを含みます。 -
&
- 例えば、query_a&query_b
(query_a
とquery_b
はここでの他のオペレータで構成されるクエリです)は、両方のクエリにマッチするキューのみを含みます。 -
!=
- 例えば、feature_category!=issue_tracking
は、issue_tracking
機能カテゴリからすべてのキューを除外します。 -
=
- 例えば、resource_boundary=cpu
は CPU バインドされているすべてのキューを含みます。 -
,
- 例えば、feature_category=continuous_integration,pages
は、continuous_integration
カテゴリまたはpages
カテゴリのすべてのキューを含みます。 この例は OR 演算子を使用しても可能ですが、より簡潔で、優先順位も低くなります。
この構文の演算子の優先順位は固定されており、ANDの優先順位をORより高くすることはできません。
GitLab 12.9以降では、上記の標準的なキューグループの構文と同様に、キューグループ全体として単一の*
、すべてのキューが選択されます。
クエリ例
/etc/gitlab/gitlab.rb
:
sidekiq['enable'] = true
sidekiq['experimental_queue_selector'] = true
sidekiq['queue_groups'] = [
# Run all non-CPU-bound queues that are high urgency
'resource_boundary!=cpu&urgency=high',
# Run all continuous integration and pages queues that are not high urgency
'feature_category=continuous_integration,pages&urgency!=high',
# Run all queues
'*'
]
Sidekiqクラスターの無効化
デフォルトでは、Sidekiqサービスはsidekiq-cluster
。 この動作を無効にするには、Sidekiq設定に以下を追加します:
sidekiq['enable'] = true
sidekiq['cluster'] = false
sidekiq
、前述のすべての設定オプションが利用可能です。 デフォルトでは、以下のように設定されます:
sidekiq['experimental_queue_selector'] = false
sidekiq['interval'] = nil
sidekiq['max_concurrency'] = 50
sidekiq['min_concurrency'] = nil
sidekiq['negate'] = false
sidekiq['queue_groups'] = ['*']
sidekiq['shutdown_timeout'] = 25
sidekiq_cluster
上記のようにクラスターを構成する場合は、無効にする必要があります。
sidekiq_cluster
を無効にする場合、sidekiq_cluster
の設定をsidekiq
にコピーする必要があります。sidekiq_cluster
で設定した内容は、sidekiq['cluster'] = true
を設定する際、sidekiq
のオプションによって上書きされます。
この機能を使用すると、sidekiq
というサービスがsidekiq-cluster
を実行するようになります。
Sidekiqに設定された同時実行およびその他のオプションが尊重されます。
デフォルトでは、sidekiq-cluster
のログは通常のSidekiqログと同様に/var/log/gitlab/sidekiq
。
すべての GitHub インポートキューを無視
GitHubからインポートする場合、Sidekiqはこれらのオペレーションを実行するためにすべてのリソースを使用する可能性があります。 すべてのGitHubインポート関連のキューを無視するように別のsidekiq-cluster
プロセスを設定するには:
-
/etc/gitlab/gitlab.rb
を編集して追加してください:sidekiq['enable'] = true sidekiq['negate'] = true sidekiq['queue_groups'] = [ "github_import_advance_stage", "github_importer:github_import_import_diff_note", "github_importer:github_import_import_issue", "github_importer:github_import_import_note", "github_importer:github_import_import_lfs_object", "github_importer:github_import_import_pull_request", "github_importer:github_import_refresh_import_jid", "github_importer:github_import_stage_finish_import", "github_importer:github_import_stage_import_base_data", "github_importer:github_import_stage_import_issues_and_diff_notes", "github_importer:github_import_stage_import_notes", "github_importer:github_import_stage_import_lfs_objects", "github_importer:github_import_stage_import_pull_requests", "github_importer:github_import_stage_import_repository" ]
-
ファイルを保存し、変更を有効にするために GitLab を再設定します:
sudo gitlab-ctl reconfigure
スレッド数
sidekiq
で定義された各プロセスは、キューの数に等しい数のスレッドと、それに予備スレッドを1つ加えた数で開始します。 例えば、process_commit
とpost_receive
のキューを処理するプロセスは、合計で3つのスレッドを使用します。
並行性の管理
最大同時実行数を設定する場合、通常は利用可能なCPUコア数を超えないように留意してください。 以下の例の値は任意であり、特に推奨するものではありません。
各スレッドにはRedis接続が必要なため、スレッドを追加するとRedisの待ち時間が長くなり、クライアントのタイムアウトを引き起こす可能性があります。 詳細については、Redisに関するSidekiqのドキュメントを参照してください。
Sidekiqクラスタ実行時(デフォルト)
GitLab 13.0以降では、Sidekiqクラスターを実行することがデフォルトとなっています。
-
/etc/gitlab/gitlab.rb
を編集して追加してください:sidekiq['min_concurrency'] = 15 sidekiq['max_concurrency'] = 25
-
ファイルを保存し、変更を有効にするために GitLab を再設定します:
sudo gitlab-ctl reconfigure
min_concurrency
max_concurrency
min_concurrency
を 0 に設定すると、リミットが無効になります。
各キューグループに対して、N をキュー数より一つ多い数とします。 同時実行係数は次のように設定されます:
-
N
min_concurrency
と の間なら。max_concurrency
-
max_concurrency
N
がこの値を超えた場合。 -
min_concurrency
N
がこの値より小さい場合。
min_concurrency
がmax_concurrency
と等しい場合、キューの数に関係なく、この値が使用されます。
min_concurrency
がmax_concurrency
, max_concurrency
より大きい場合、max_concurrency
それは , と等しいものとして扱 max_concurrency
われます。
Sidekiqプロセスを1つ実行する場合
GitLab 12.10以前では、単一のSidekiqプロセスを実行するのがデフォルトです。
-
/etc/gitlab/gitlab.rb
を編集して追加してください:sidekiq['cluster'] = false sidekiq['concurrency'] = 25
-
ファイルを保存し、変更を有効にするために GitLab を再設定します:
sudo gitlab-ctl reconfigure
Sidekiqプロセスの同時実行数(スレッド数)を設定します。
チェック間隔の変更
追加Sidekiqプロセスのチェック間隔を変更するには:
-
/etc/gitlab/gitlab.rb
を編集して追加してください:sidekiq['interval'] = 5
-
ファイルを保存し、変更を有効にするために GitLab を再設定します。
これは、キューイングされているジョブをチェックする頻度を追加プロセスに指示します。
CLIを使用したトラブルシューティング
/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, ...]
それぞれの個別の引数は、Sidekiqプロセスによって処理されなければならないキューのグループを示します。 複数のキューは、スペースではなくカンマで区切ることによって、同じプロセスによって処理することができます。
キューの代わりにキュー名前空間を指定することで、すべてのキュー名を明示的に列挙することなく、その名前空間内のすべてのキューをプロセスが自動的にリッスンするようにすることもできます。 キュー名前空間の詳細については、Sidekiqスタイルガイドの関連セクションを参照してください。
例えば、process_commit
のキューを処理するプロセスと、post_receive
のキューを処理するプロセスの、2つのプロセスを追加で起動したいとします。 これは、以下のようにして実行できます:
/opt/gitlab/embedded/service/gitlab-rails/bin/sidekiq-cluster process_commit post_receive
代わりに、両方のキューを処理する1つのプロセスを開始したい場合は、以下の構文を使用します:
/opt/gitlab/embedded/service/gitlab-rails/bin/sidekiq-cluster process_commit,post_receive
1つのSidekiqプロセスでprocess_commit
、post_receive
キューを処理し、1つのプロセスでgitlab_shell
キューを処理したい場合、次のようにします:
/opt/gitlab/embedded/service/gitlab-rails/bin/sidekiq-cluster process_commit,post_receive gitlab_shell
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プロセスのPIDではなく、sidekiq-cluster
コマンドのPIDがコンテナとして格納されることに注意してください。
環境
Rails環境を設定するには、sidekiq-cluster
コマンドに--environment
フラグを渡すか、RAILS_ENV
に空でない値を設定します。デフォルト値は/opt/gitlab/etc/gitlab-rails/env/RAILS_ENV
にあります。