• 利用可能なSidekiqキュー
• 複数のプロセスの開始
• ネガティブ設定
• キューセレクタ（実験的）
  • 利用可能な属性
  • 利用可能なオペレーション
  • クエリ例
  • Sidekiqクラスターの無効化
• すべての GitHub インポートキューを無視
• スレッド数
• 並行性の管理
  • Sidekiqクラスタ実行時(デフォルト)
  • Sidekiqプロセスを1つ実行する場合
• チェック間隔の変更
• CLIを使用したトラブルシューティング
  • sidekiq-cluster コマンドの監視
  • PIDファイル
  • 環境

複数のSidekiqプロセスの実行

GitLabでは、複数のSidekiqプロセスを起動することができます。 これらのプロセスは、専用のキューセットを消費するために使用することができます。 これは、処理する必要があるジョブの数に関係なく、特定のキューが常に専用のワーカーを持つようにするために使用することができます。

利用可能なSidekiqキュー

既存のSidekiqキューのリストについては、以下のファイルを確認してください：

• GitLab Community EditionとEnterprise Edition両方のキュー
• GitLab Enterpriseエディションのみのキュー

上記ファイルの各エントリーは、Sidekiqプロセスを開始できるキューを表します。

複数のプロセスの開始

• GitLab 12.10で導入された、Sidekiqクラスターによる複数プロセスの起動。
• Sidekiq クラスターは GitLab 12.10 で GitLabCoreに移動しました。
• GitLab 13.0でSidekiqクラスターがデフォルトになりました。

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

1. 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 を使用して、すでに処理されているすべてのキューを一覧表示することもできます。

2. ファイルを保存し、変更を有効にするために GitLab を再設定します：

   sudo gitlab-ctl reconfigure
   

Sidekiqプロセスを追加したら、GitLabの Admin Area > Monitoring > Background Jobs(/admin/background_jobs) に移動します。

ネガティブ設定

追加Sidekiqプロセスを、リストしたキュー以外のすべてのキューで動作させるには：

1. 追加プロセスを開始する手順を踏んだら、/etc/gitlab/gitlab.rb を編集して追加します：

   sidekiq['negate'] = true
   

2. ファイルを保存し、変更を有効にするために 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 プロセスを設定するには：

1. /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"
   ]
   

2. ファイルを保存し、変更を有効にするために GitLab を再設定します：

   sudo gitlab-ctl reconfigure
   

スレッド数

sidekiq で定義された各プロセスは、キューの数に等しい数のスレッドと、それに予備スレッドを1つ加えた数で開始します。 例えば、process_commit とpost_receiveのキューを処理するプロセスは、合計で3つのスレッドを使用します。

並行性の管理

最大同時実行数を設定する場合、通常は利用可能なCPUコア数を超えないように留意してください。 以下の例の値は任意であり、特に推奨するものではありません。

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

Sidekiqクラスタ実行時(デフォルト)

GitLab 13.0以降では、Sidekiqクラスターを実行することがデフォルトとなっています。

1. /etc/gitlab/gitlab.rb を編集して追加してください：

   sidekiq['min_concurrency'] = 15
   sidekiq['max_concurrency'] = 25
   

2. ファイルを保存し、変更を有効にするために GitLab を再設定します：

   sudo gitlab-ctl reconfigure
   

min_concurrency max_concurrency min_concurrency を 0 に設定すると、リミットが無効になります。

各キューグループに対して、N をキュー数より一つ多い数とします。 同時実行係数は次のように設定されます：

1. Nmin_concurrency と の間なら。max_concurrency
2. max_concurrencyN がこの値を超えた場合。
3. min_concurrencyN がこの値より小さい場合。

min_concurrency がmax_concurrencyと等しい場合、キューの数に関係なく、この値が使用されます。

min_concurrency がmax_concurrency, max_concurrencyより大きい場合、max_concurrencyそれは , と等しいものとして扱 max_concurrencyわれます。

Sidekiqプロセスを1つ実行する場合

GitLab 12.10以前では、単一のSidekiqプロセスを実行するのがデフォルトです。

1. /etc/gitlab/gitlab.rb を編集して追加してください：

   sidekiq['cluster'] = false
   sidekiq['concurrency'] = 25
   

2. ファイルを保存し、変更を有効にするために GitLab を再設定します：

   sudo gitlab-ctl reconfigure
   

Sidekiqプロセスの同時実行数（スレッド数）を設定します。

チェック間隔の変更

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

1. /etc/gitlab/gitlab.rb を編集して追加してください：

   sidekiq['interval'] = 5
   

2. ファイルを保存し、変更を有効にするために GitLab を再設定します。

これは、キューイングされているジョブをチェックする頻度を追加プロセスに指示します。

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

デバッグのために、/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にあります。