Sidekiqジョブへのログ引数
Sidekiqキューのバックログやパフォーマンス低下の調査
スレッドダンプ
によるRubyプロファイリングrbspy
によるプロセス・プロファイリングperf
GNUプロジェクトデバッガ (gdb)
Sidekiq killシグナル
クエリのブロックチェック
Sidekiqキューの管理
実行中のジョブのキャンセル（破壊的）
手動でcronジョブを起動する方法
Sidekiqジョブ重複排除キーのクリア
GitLab 14.0 以降：sidekiq-cluster サービスを削除（Linux パッケージインストール）
関連するトピック

Sidekiqのトラブルシューティング

Sidekiqは、GitLabがタスクを非同期に実行するために使うバックグラウンドジョブプロセッサです。うまくいかないとき、トラブルシューティングをするのは難しいかもしれません。このような状況は、本番システムのジョブキューが一杯になってしまうため、プレッシャーも高くなりがちです。新しいブランチが表示されなかったりマージリクエストが更新されなかったりするため、ユーザーはこのような状況に気づきます。ボトルネックの診断に役立つトラブルシューティングの手順を以下に示します。

GitLab管理者/ユーザーは、バックトレースを私たちのチームが分析できるように、これらのデバッグステップをGitLabサポートと一緒に作業することを検討してください。GitLabのバグや必要な改善が見つかるかもしれません。

どのバックトレースでも、すべてのスレッドがデータベースやRedisで待機しているように見えたり、ミューテックスの取得を待っているように見えたりする場合は疑ってください。これは、例えばデータベースで競合が発生していることを意味するかもしれませんが、他のスレッドとは異なるスレッドを探してください。この他のスレッドは、利用可能なCPUをすべて使っているか、Rubyグローバルインタープリタロックを持っていて、他のスレッドの続行を妨げている可能性があります。

Sidekiqジョブへのログ引数

GitLab 13.6以降では、Sidekiqジョブに渡されるいくつかの引数はデフォルトでログに記録されます。機密情報(インスタンスンスンス、パスワードリセットトークン)のログを避けるために、GitLabは全てのワーカーに対して数値引数をログに記録します。

ログの出力例

{"severity":"INFO","time":"2020-06-08T14:37:37.892Z","class":"AdminEmailsWorker","args":["[FILTERED]","[FILTERED]","[FILTERED]"],"retry":3,"queue":"admin_emails","backtrace":true,"jid":"9e35e2674ac7b12d123e13cc","created_at":"2020-06-08T14:37:37.373Z","meta.user":"root","meta.caller_id":"Admin::EmailsController#create","correlation_id":"37D3lArJmT1","uber-trace-id":"2d942cc98cc1b561:6dc94409cfdd4d77:9fbe19bdee865293:1","enqueued_at":"2020-06-08T14:37:37.410Z","pid":65011,"message":"AdminEmailsWorker JID-9e35e2674ac7b12d123e13cc: done: 0.48085 sec","job_status":"done","scheduling_latency_s":0.001012,"redis_calls":9,"redis_duration_s":0.004608,"redis_read_bytes":696,"redis_write_bytes":6141,"duration_s":0.48085,"cpu_s":0.308849,"completed_at":"2020-06-08T14:37:37.892Z","db_duration_s":0.010742}
{"severity":"INFO","time":"2020-06-08T14:37:37.894Z","class":"ActiveJob::QueueAdapters::SidekiqAdapter::JobWrapper","wrapped":"ActionMailer::MailDeliveryJob","queue":"mailers","args":["[FILTERED]"],"retry":3,"backtrace":true,"jid":"e47a4f6793d475378432e3c8","created_at":"2020-06-08T14:37:37.884Z","meta.user":"root","meta.caller_id":"AdminEmailsWorker","correlation_id":"37D3lArJmT1","uber-trace-id":"2d942cc98cc1b561:29344de0f966446d:5c3b0e0e1bef987b:1","enqueued_at":"2020-06-08T14:37:37.885Z","pid":65011,"message":"ActiveJob::QueueAdapters::SidekiqAdapter::JobWrapper JID-e47a4f6793d475378432e3c8: start","job_status":"start","scheduling_latency_s":0.009473}
{"severity":"INFO","time":"2020-06-08T14:39:50.648Z","class":"NewIssueWorker","args":["455","1"],"retry":3,"queue":"new_issue","backtrace":true,"jid":"a24af71f96fd129ec47f5d1e","created_at":"2020-06-08T14:39:50.643Z","meta.user":"root","meta.project":"h5bp/html5-boilerplate","meta.root_namespace":"h5bp","meta.caller_id":"Projects::IssuesController#create","correlation_id":"f9UCZHqhuP7","uber-trace-id":"28f65730f99f55a3:a5d2b62dec38dffc:48ddd092707fa1b7:1","enqueued_at":"2020-06-08T14:39:50.646Z","pid":65011,"message":"NewIssueWorker JID-a24af71f96fd129ec47f5d1e: start","job_status":"start","scheduling_latency_s":0.001144}

Sidekiq JSONロギングを使用する場合、引数ログのテキストサイズは最大10キロバイトに制限されます。この制限を超えた引数は破棄され、文字列"..." を含む単一の引数に置き換えられます。

引数のログを無効にするには、SIDEKIQ_LOG_ARGUMENTS 環境変数を 0 (false) に設定します。

使用例：

gitlab_rails['env'] = {"SIDEKIQ_LOG_ARGUMENTS" => "0"}

GitLab 13.5以前では、SIDEKIQ_LOG_ARGUMENTS を1 に設定すると、Sidekiqに渡された引数のロギングを開始します。

Sidekiqキューのバックログやパフォーマンス低下の調査

Sidekiqのパフォーマンスが低下する症状には、マージリクエストのステータス更新の問題や、CIパイプラインの実行開始前の遅延などがあります。

可能性のある原因は以下のとおりです：

GitLabインスタンスがより多くのSidekiqワーカーを必要としている可能性があります。デフォルトでは、シングルノードLinuxパッケージインストールではワーカーが1つ実行され、Sidekiqジョブの実行は最大1CPUコアに制限されます。複数のSidekiqワーカーの実行についての詳細をお読みください。
インスタンスにはより多くのSidekiqワーカーが設定されていますが、余分なワーカーのほとんどはキューに入ったジョブを実行するように設定されていません。このため、インスタンスがビジー状態の時や、ワーカーが設定されてから数ヶ月または数年の間にワークロードが変化した場合、またはGitLab製品の変更の結果として、ジョブのバックログが発生する可能性があります。

以下のRubyスクリプトを使って、Sidekiqワーカーの状態に関するデータを収集しましょう。

スクリプトを作成します：

cat > /var/opt/gitlab/sidekiqcheck.rb <<EOF
require 'sidekiq/monitor'
Sidekiq::Monitor::Status.new.display('overview')
Sidekiq::Monitor::Status.new.display('processes'); nil
Sidekiq::Monitor::Status.new.display('queues'); nil
puts "----------- workers ----------- "
workers = Sidekiq::Workers.new
workers.each do |_process_id, _thread_id, work|
  pp work
end
puts "----------- Queued Jobs ----------- "
Sidekiq::Queue.all.each do |queue|
  queue.each do |job|
    pp job
  end
end ;nil
puts "----------- done! ----------- "
EOF

実行し、出力をキャプチャします：
```
sudo gitlab-rails runner /var/opt/gitlab/sidekiqcheck.rb > /tmp/sidekiqcheck_$(date '+%Y%m%d-%H:%M').out
```
パフォーマンスのイシューが断続的な場合：
- 5分ごとにcronジョブでこれを実行してください。十分なスペースのある場所にファイルを書き込んでください：1ファイルあたり少なくとも500KBは確保してください。
```
 cat > /etc/cron.d/sidekiqcheck <<EOF
 */5 * * * *  root  /opt/gitlab/bin/gitlab-rails runner /var/opt/gitlab/sidekiqcheck.rb > /tmp/sidekiqcheck_$(date '+\%Y\%m\%d-\%H:\%M').out 2>&1
 EOF
```
- 何が問題だったかを確認するために、データを参照してください。
出力の分析以下のコマンドは、出力ファイルのディレクトリがあることを前提としています。
1. grep 'Busy: ' * grep 'Enqueued: ' * はその時点のバックログを示します。
2. Sidekiqに負荷がかかっているサンプルのワーカー全体のビジー・スレッド数を見てください：
```
ls | while read f ; do if grep -q 'Enqueued: 0' $f; then :
  else echo $f; egrep 'Busy:|Enqueued:|---- Processes' $f
  grep 'Threads:' $f ; fi
done | more
```
  出力例です：
```
sidekiqcheck_20221024-14:00.out
       Busy: 47
   Enqueued: 363
---- Processes (13) ----
  Threads: 30 (0 busy)
  Threads: 30 (0 busy)
  Threads: 30 (0 busy)
  Threads: 30 (0 busy)
  Threads: 23 (0 busy)
  Threads: 30 (0 busy)
  Threads: 30 (0 busy)
  Threads: 30 (0 busy)
  Threads: 30 (0 busy)
  Threads: 30 (0 busy)
  Threads: 30 (0 busy)
  Threads: 30 (24 busy)
  Threads: 30 (23 busy)
```
  - この出力ファイルでは、47スレッドがビジー状態で、363ジョブのバックログがありました。
  - 13 のワーカープロセスのうち、ビジーだったのは 2 つだけです。
  - これは、他のワーカーの設定が特殊すぎることを示しています。
  - どのワーカーがビジー状態だったかを調べるために、完全な出力を見てください。gitlab.rb でsidekiq_queues の設定と照らし合わせてください。
  - 過負荷のシングルワーカー環境は次のようになります：
    sidekiqcheck_20221024-14:00.out Busy: 25 Enqueued: 363 ---- Processes (1) ---- Threads: 25 (25 busy)
3. 出力ファイルの---- Queues (xxx) ---- セクションを見て、その時点でキューに入っていたジョブを判断してください。
4. ファイルには、その時点でのSidekiqの状態に関する低レベルの詳細も含まれています。これは、ワークロードの急増がどこから生じているかを特定するのに役立つ可能性があります。
  - ----------- workers ----------- セクションには、サマリーのBusy カウントを構成するジョブの詳細が記載されています。
  - ----------- Queued Jobs ----------- セクションには、Enqueued のジョブの詳細が記載されています。

スレッドダンプ

SidekiqプロセスIDにTTIN シグナルを送り、スレッドのバックトレースをログファイルに出力します。

kill -TTIN <sidekiq_pid>

バックトレース出力は/var/log/gitlab/sidekiq/current または$GITLAB_HOME/log/sidekiq.log で確認してください。バックトレースは長く、一般的にいくつかのWARN レベルのメッセージから始まります。以下はシングルスレッドのバックトレースの例です：

2016-04-13T06:21:20.022Z 31517 TID-orn4urby0 WARN: ActiveRecord::RecordNotFound: Couldn't find Note with 'id'=3375386
2016-04-13T06:21:20.022Z 31517 TID-orn4urby0 WARN: /opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/activerecord-4.2.5.2/lib/active_record/core.rb:155:in `find'
/opt/gitlab/embedded/service/gitlab-rails/app/workers/new_note_worker.rb:7:in `perform'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/sidekiq-4.0.1/lib/sidekiq/processor.rb:150:in `execute_job'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/sidekiq-4.0.1/lib/sidekiq/processor.rb:132:in `block (2 levels) in process'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/sidekiq-4.0.1/lib/sidekiq/middleware/chain.rb:127:in `block in invoke'
/opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/sidekiq_middleware/memory_killer.rb:17:in `call'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/sidekiq-4.0.1/lib/sidekiq/middleware/chain.rb:129:in `block in invoke'
/opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/sidekiq_middleware/arguments_logger.rb:6:in `call'
...

Sidekiqがハングし、TTIN シグナルに応答できない場合があります。このような場合は、他のトラブルシューティング方法に進んでください。

によるRubyプロファイリング`rbspy`

rbspyは使いやすく、RubyプロセスのCPU使用率のフレームグラフを作成できるRubyプロファイラです。

GitLab を変更する必要はなく、依存関係もありません。インストールするには

rbspy リリースページからバイナリをダウンロードしてください。
バイナリを実行可能にします。

Sidekiqワーカーを1分間プロファイリングするには、実行します：

sudo ./rbspy record --pid <sidekiq_pid> --duration 60 --file /tmp/sidekiq_profile.svg

このrbspy によって生成されたフレームグラフの例では、Sidekiqプロセスのほぼすべての時間が、rev_parseRuggedのネイティブC関数に rev_parse費やされています。rev_parseスタックでは rev_parse、ExpirePipelineCacheWorker 。

によるプロセス・プロファイリング`perf`

Linuxには、perf と呼ばれるプロセスプロファイリングツールがあり、特定のプロセスがCPUを大量に消費している場合に役立ちます。CPU使用率が高く、SidekiqがTTIN シグナルに反応しない場合、これは良い次のステップです。

perf がシステムにインストールされていない場合は、apt-get またはyum と一緒にインストールしてください：

# Debian
sudo apt-get install linux-tools

# Ubuntu (may require these additional Kernel packages)
sudo apt-get install linux-tools-common linux-tools-generic linux-tools-`uname -r`

# Red Hat/CentOS
sudo yum install perf

Sidekiq PIDに対してperf ：

sudo perf record -p <sidekiq_pid>

30～60秒間実行し、Ctrl-Cを押します。その後、perf のレポートを表示します：

$ sudo perf report

# Sample output
Samples: 348K of event 'cycles', Event count (approx.): 280908431073
 97.69%            ruby  nokogiri.so         [.] xmlXPathNodeSetMergeAndClear
  0.18%            ruby  libruby.so.2.1.0    [.] objspace_malloc_increase
  0.12%            ruby  libc-2.12.so        [.] _int_malloc
  0.10%            ruby  libc-2.12.so        [.] _int_free

上記はperf レポートのサンプル出力です。CPUの97%がNokogiriとxmlXPathNodeSetMergeAndClear の内部で使われていることがわかります。GitLabのどのジョブがNokogiriとXPathを使っているか調べてみましょう。TTIN やgdb の出力と組み合わせて、この現象が起きているRubyコードを表示します。

GNUプロジェクトデバッガ (`gdb`)

gdb は、Sidekiqをデバッグするためのもう一つの効果的なツールです。これは、各スレッドを見て、何が問題を引き起こしているかを確認するための、もう少しインタラクティブな方法を提供します。

gdb でプロセスにアタッチすると、プロセスの標準オペレーションが一時停止します（Sidekiqは、gdb がアタッチされている間、ジョブを処理しません）。

まずはSidekiqのPIDにアタッチしてください：

gdb -p <sidekiq_pid>

次に、すべてのスレッドの情報を収集します：

info threads

# Example output
Thread 0x7fe5fbd63700 (LWP 26060) 0x0000003f7cadf113 in poll () from /lib64/libc.so.6
Thread 0x7fe5f2b3b700 (LWP 26533) 0x0000003f7ce0b68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
Thread 0x7fe5f2a3a700 (LWP 26534) 0x0000003f7ce0ba5e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
Thread 0x7fe5f2939700 (LWP 26535) 0x0000003f7ce0b68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
Thread 0x7fe5f2838700 (LWP 26537) 0x0000003f7ce0b68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
Thread 0x7fe5f2737700 (LWP 26538) 0x0000003f7ce0b68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
Thread 0x7fe5f2535700 (LWP 26540) 0x0000003f7ce0b68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
Thread 0x7fe5f2434700 (LWP 26541) 0x0000003f7ce0b68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
Thread 0x7fe5f2232700 (LWP 26543) 0x0000003f7ce0b68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
Thread 0x7fe5f2131700 (LWP 26544) 0x00007fe5f7b570f0 in xmlXPathNodeSetMergeAndClear ()
from /opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/nokogiri-1.6.7.2/lib/nokogiri/nokogiri.so
...

上の「ノコギリ」のような怪しいスレッドがあったら、もっと情報を集めたほうがいいかもしれません：

thread 21
bt

# Example output
#0  0x00007ff0d6afe111 in xmlXPathNodeSetMergeAndClear () from /opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/nokogiri-1.6.7.2/lib/nokogiri/nokogiri.so
#1  0x00007ff0d6b0b836 in xmlXPathNodeCollectAndTest () from /opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/nokogiri-1.6.7.2/lib/nokogiri/nokogiri.so
#2  0x00007ff0d6b09037 in xmlXPathCompOpEval () from /opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/nokogiri-1.6.7.2/lib/nokogiri/nokogiri.so
#3  0x00007ff0d6b09017 in xmlXPathCompOpEval () from /opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/nokogiri-1.6.7.2/lib/nokogiri/nokogiri.so
#4  0x00007ff0d6b092e0 in xmlXPathCompOpEval () from /opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/nokogiri-1.6.7.2/lib/nokogiri/nokogiri.so
#5  0x00007ff0d6b0bc37 in xmlXPathRunEval () from /opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/nokogiri-1.6.7.2/lib/nokogiri/nokogiri.so
#6  0x00007ff0d6b0be5f in xmlXPathEvalExpression () from /opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/nokogiri-1.6.7.2/lib/nokogiri/nokogiri.so
#7  0x00007ff0d6a97dc3 in evaluate (argc=2, argv=0x1022d058, self=<value optimized out>) at xml_xpath_context.c:221
#8  0x00007ff0daeab0ea in vm_call_cfunc_with_frame (th=0x1022a4f0, reg_cfp=0x1032b810, ci=<value optimized out>) at vm_insnhelper.c:1510

すべてのスレッドのバックトレースを一度に出力するには：

set pagination off
thread apply all bt

gdb でのデバッグが終わったら、必ずプロセスから切り離して終了してください：

detach
exit

Sidekiq killシグナル

TTINは、ロギングのためにバックトレースを出力するシグナルとして上記で説明しましたが、Sidekiqは他のシグナルにも応答します。たとえば、TSTPとTERMは、Sidekiqを優雅にシャットダウンするために使用できます。

クエリのブロックチェック

Sidekiqがジョブを処理するスピードが速すぎて、データベースの競合が発生することがあります。上記のバックトレースで、多くのスレッドがデータベースアダプタでスタックしていることが確認された場合は、クエリがブロックされていないか確認してください。

PostgreSQL wikiに、ブロッキングクエリを確認するために実行できるクエリの詳細があります。クエリはPostgreSQLのバージョンによって異なります。クエリの詳細はロック監視を参照してください。

Sidekiqキューの管理

Sidekiq APIを使用して、Sidekiq上で多くのトラブルシューティングを実行することが可能です。

これらは管理コマンドであり、インストールの規模により現在の管理インターフェイスが適切でない場合にのみ使用する必要があります。

これらのコマンドはすべてgitlab-rails console を使って実行してください。

キューサイズの表示

Sidekiq::Queue.new("pipeline_processing:build_queue").size

キューに登録されているジョブの一覧表示

queue = Sidekiq::Queue.new("chaos:chaos_sleep")
queue.each do |job|
  # job.klass # => 'MyWorker'
  # job.args # => [1, 2, 3]
  # job.jid # => jid
  # job.queue # => chaos:chaos_sleep
  # job["retry"] # => 3
  # job.item # => {
  #   "class"=>"Chaos::SleepWorker",
  #   "args"=>[1000],
  #   "retry"=>3,
  #   "queue"=>"chaos:chaos_sleep",
  #   "backtrace"=>true,
  #   "queue_namespace"=>"chaos",
  #   "jid"=>"39bc482b823cceaf07213523",
  #   "created_at"=>1566317076.266069,
  #   "correlation_id"=>"c323b832-a857-4858-b695-672de6f0e1af",
  #   "enqueued_at"=>1566317076.26761},
  # }

  # job.delete if job.jid == 'abcdef1234567890'
end

現在実行中のジョブの列挙

workers = Sidekiq::Workers.new
workers.each do |process_id, thread_id, work|
  # process_id is a unique identifier per Sidekiq process
  # thread_id is a unique identifier per thread
  # work is a Hash which looks like:
  # {"queue"=>"chaos:chaos_sleep",
  #  "payload"=>
  #  { "class"=>"Chaos::SleepWorker",
  #    "args"=>[1000],
  #    "retry"=>3,
  #    "queue"=>"chaos:chaos_sleep",
  #    "backtrace"=>true,
  #    "queue_namespace"=>"chaos",
  #    "jid"=>"b2a31e3eac7b1a99ff235869",
  #    "created_at"=>1566316974.9215662,
  #    "correlation_id"=>"e484fb26-7576-45f9-bf21-b99389e1c53c",
  #    "enqueued_at"=>1566316974.9229589},
  #  "run_at"=>1566316974}],
end

指定されたパラメータのSidekiqジョブを削除(破壊的)

条件付きでジョブを強制終了する一般的な方法は次のコマンドで、キューには入っているが開始されていないジョブを削除します。実行中のジョブを強制終了することはできません。

queue = Sidekiq::Queue.new('<queue name>')
queue.each { |job| job.delete if <condition>}

実行中のジョブのキャンセルについては以下のセクションをご覧ください。

上記のメソッドでは、<queue-name> が削除したいジョブを含むキューの名前で、<condition> が削除されるジョブを決定します。

一般的に、<condition> はジョブの引数を参照します。引数は問題のジョブの種類によって異なります。/app/workers/<queue-name>_worker.rb特定のキューの引数を見つけるには、関連するワーカーファイルのperform 関数を参照してください。

例えば、repository_import はジョブ引数としてproject_id を持ち、update_merge_requests はproject_id, user_id, oldrev, newrev, refを持ちます。

job.args はSidekiqジョブに提供されるすべての引数のリストであるため、引数はjob.args[<id>] を使用してそれらのシーケンスIDによって参照される必要があります。

以下に例を示します：

queue = Sidekiq::Queue.new('update_merge_requests')
# In this example, we want to remove any update_merge_requests jobs
# for the Project with ID 125 and ref `ref/heads/my_branch`
queue.each { |job| job.delete if job.args[0] == 125 and job.args[4] == 'ref/heads/my_branch' }

# Cancelling jobs like: `RepositoryImportWorker.new.perform_async(100)`
id_list = [100]

queue = Sidekiq::Queue.new('repository_import')
queue.each do |job|
  job.delete if id_list.include?(job.args[0])
end

特定のジョブIDを削除（破壊的）

queue = Sidekiq::Queue.new('repository_import')
queue.each do |job|
  job.delete if job.jid == 'my-job-id'
end

実行中のジョブのキャンセル（破壊的）

GitLab 12.3 で導入されました。

これは非常にリスクの高いオペレーションなので、最後の手段として使ってください。ジョブの実行が途中で中断され、トランザクションの適切なロールバックが保証されないためです。

Gitlab::SidekiqDaemon::Monitor.cancel_job('job-id')

そのため、SidekiqをSIDEKIQ_MONITOR_WORKER=1 環境変数で実行する必要があります。

Thread.raise Rubyのタイムアウトが危険な理由（そしてThread.raiseが恐ろしい理由）で述べたように、多くの欠点があります：

これが面白いところであり、恐ろしいところでもあります。これは例外が発生する可能性があることを意味します：

ネットワークリクエスト中に(周囲のコードがTimeout::Errorをキャッチする準備ができていれば大丈夫です)
ネットワークリクエストのクリーンアップ中
レスキューブロック中
その後データベースに保存するオブジェクトの作成中
の前に例外を発生させることができたかどうかに関係なく、どのコードでも
文字どおり、どの行でも例外が発生しないようにコードを書く人はいません。そんなことは不可能です。つまり、スレッド.raise は基本的に、あなたのコードに対するお忍び攻撃のようなもので、その結果ほとんど何でもあり得るのです。状態を変更しない純粋に機能的なコードであれば、おそらく大丈夫でしょう。でもこれはRubyなので、そんなことはありえないでしょう:)

手動でcronジョブを起動する方法

/admin/background_jobs にアクセスすることで、インスタンス上でスケジュール/実行/保留されているジョブを調べることができます。

UIから “Enqueue Now “ボタンを選択することで、cronジョブを起動できます。プログラムでcronジョブを起動するには、まずRailsコンソールを開いてください。

テストしたいcronジョブを探します：

job = Sidekiq::Cron::Job.find('job-name')

# get status of job:
job.status

# enqueue job right now!
job.enque!

例えば、リポジトリのミラーを更新するupdate_all_mirrors_worker cron ジョブを起動します：

irb(main):001:0> job = Sidekiq::Cron::Job.find('update_all_mirrors_worker')
=>
#<Sidekiq::Cron::Job:0x00007f147f84a1d0
...
irb(main):002:0> job.status
=> "enabled"
irb(main):003:0> job.enque!
=> 257

利用可能なジョブのリストはworkersディレクトリにあります。

Sidekiqジョブの詳細については、Sidekiq-cronドキュメントを参照してください。

Sidekiqジョブ重複排除キーのクリア

時折、実行が期待されるジョブ（cronジョブなど）がまったく実行されないことがあります。ログをチェックすると、ジョブが"job_status": "deduplicated".

これは、ジョブが失敗し、idempotencyキーが適切にクリアされなかった場合に発生する可能性があります。例えば、Sidekiqを停止すると、25秒後に残りのジョブがすべて停止します。

デフォルトでは、キーは6時間後に失効しますが、すぐにidempotencyキーをクリアしたい場合は、次の手順に従ってください(提供される例はGeo::VerificationBatchWorker)：

Sidekiqログからジョブのワーカークラスとargs ：

{ ... "class":"Geo::VerificationBatchWorker","args":["container_repository"] ... }

Railsコンソールセッションを開始します。
次のスニペットを実行します：

worker_class = Geo::VerificationBatchWorker
args = ["container_repository"]
dj = Gitlab::SidekiqMiddleware::DuplicateJobs::DuplicateJob.new({ 'class' => worker_class.name, 'args' => args }, worker_class.queue)
dj.send(:idempotency_key)
dj.delete!

GitLab 14.0 以降：`sidekiq-cluster` サービスを削除（Linux パッケージインストール）

GitLab 14.0より前にsidekiq-cluster を実行するように設定されたLinuxパッケージインスタンスは、それ以降のリリースでもsidekiq とともにこのサービスが実行されている可能性があります。

管理するコードはsidekiq-cluster GitLab 14.0で削除 sidekiq-clusterされました。sidekiq-cluster 設定ファイルはディスク上に残っているので sidekiq-cluster、GitLab systemdサービスによってプロセスが開始され続けます。

余分なサービスは以下によって実行されていることが確認できます：

gitlab-ctl status 両方のサービスを表示

 run: sidekiq: (pid 1386) 445s; run: log: (pid 1385) 445s
 run: sidekiq-cluster: (pid 1388) 445s; run: log: (pid 1381) 445s

ps -ef | grep 'runsv sidekiq' 2つのプロセスを表示

 root     31047 31045  0 13:54 ?        00:00:00 runsv sidekiq-cluster
 root     31054 31045  0 13:54 ?        00:00:00 runsv sidekiq

GitLab 14.0 以降を実行しているサーバーからsidekiq-cluster サービスを削除するには：

GitLab と systemd サービスを停止します：

sudo gitlab-ctl stop
sudo systemctl stop gitlab-runsvdir.service

runsv サービス定義を削除します：

sudo rm -rf /opt/gitlab/sv/sidekiq-cluster

GitLabを再起動します：

sudo systemctl start gitlab-runsvdir.service

すべてのサービスが立ち上がっていること、そしてsidekiq-cluster サービスがリストにないことを確認してください：
```
sudo gitlab-ctl status
```

この変更により、Sidekiqの作業量が減少する可能性があります。パイプライン作成の遅延などの症状は、Sidekiqプロセスの追加が有益であることを示しています。sidekiq-cluster サービスの削除を補うため、Sidekiq プロセスの追加を検討してください。

Elasticsearch ワーカーの過負荷 Sidekiq.

Sidekiqのトラブルシューティング

Sidekiqジョブへのログ引数

Sidekiqキューのバックログやパフォーマンス低下の調査

スレッドダンプ

によるRubyプロファイリング`rbspy`

によるプロセス・プロファイリング`perf`

GNUプロジェクトデバッガ (`gdb`)

Sidekiq killシグナル

クエリのブロックチェック

Sidekiqキューの管理

キューサイズの表示

キューに登録されているジョブの一覧表示

現在実行中のジョブの列挙

指定されたパラメータのSidekiqジョブを削除(破壊的)

特定のジョブIDを削除（破壊的）

実行中のジョブのキャンセル（破壊的）

手動でcronジョブを起動する方法

Sidekiqジョブ重複排除キーのクリア

GitLab 14.0 以降：`sidekiq-cluster` サービスを削除（Linux パッケージインストール）

Help & feedback

Docs

Product

Feature availability and product trials

Get Help

Sidekiqのトラブルシューティング

Sidekiqジョブへのログ引数

Sidekiqキューのバックログやパフォーマンス低下の調査

スレッドダンプ

によるRubyプロファイリングrbspy

によるプロセス・プロファイリングperf

GNUプロジェクトデバッガ (gdb)

Sidekiq killシグナル

クエリのブロックチェック

Sidekiqキューの管理

キューサイズの表示

キューに登録されているジョブの一覧表示

現在実行中のジョブの列挙

指定されたパラメータのSidekiqジョブを削除(破壊的)

特定のジョブIDを削除（破壊的）

実行中のジョブのキャンセル（破壊的）

手動でcronジョブを起動する方法

Sidekiqジョブ重複排除キーのクリア

GitLab 14.0 以降：sidekiq-cluster サービスを削除（Linux パッケージインストール）

関連するトピック

Help & feedback

Docs

Product

Feature availability and product trials

Get Help

によるRubyプロファイリング`rbspy`

によるプロセス・プロファイリング`perf`

GNUプロジェクトデバッガ (`gdb`)

GitLab 14.0 以降：`sidekiq-cluster` サービスを削除（Linux パッケージインストール）