Sidekiq은 GitLab이 작업을 비동기적으로 실행하는 데 사용하는 백그라운드 잡 처리기입니다. 문제가 발생하면 문제를 해결하기 어려울 수 있습니다. 프로덕션 시스템의 잡 대기열이 가득 찰 수 있기 때문에 이러한 상황은 높은 압박감을 주는 경향이 있습니다. 새 브랜치가 표시되지 않거나 머지 리퀘스트가 업데이트되지 않을 때 사용자들이 이를 알아차립니다. 다음은 병목 현상을 진단하는 데 도움이 되는 몇 가지 문제 해결 단계입니다.

GitLab 관리자/사용자는 GitLab 지원팀과 함께 이러한 디버그 단계를 수행하여 백트레이스를 팀이 분석할 수 있도록 해야 합니다. GitLab의 버그나 필요한 개선 사항이 드러날 수 있습니다.

백트레이스에서 모든 스레드가 데이터베이스, Redis에서 대기하거나 뮤텍스 획득을 기다리는 경우를 의심할 때 주의하세요. 이것이 예를 들어 데이터베이스의 경합을 의미할 수도 있지만, 나머지와 다른 하나의 스레드를 찾아보세요. 이 다른 스레드가 가용한 모든 CPU를 사용하거나 다른 스레드가 계속 실행되지 못하게 하는 Ruby 글로벌 인터프리터 잠금을 가질 수 있습니다.

Sidekiq 잡에 인수 로깅#

일부 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"}

Sidekiq 대기열 백로그 또는 느린 성능 조사#

느린 Sidekiq 성능의 증상에는 머지 리퀘스트 상태 업데이트 문제와 CI 파이프라인 시작 전 지연이 포함됩니다.

잠재적 원인은 다음과 같습니다:

• GitLab 인스턴스에 더 많은 Sidekiq 워커가 필요할 수 있습니다. 기본적으로 단일 노드 Linux 패키지 설치는 하나의 워커를 실행하여 Sidekiq 잡 실행을 최대 하나의 CPU 코어로 제한합니다. 여러 Sidekiq 워커 실행에 대해 자세히 알아보세요.

• 인스턴스가 더 많은 Sidekiq 워커로 구성되어 있지만 대부분의 추가 워커가 대기 중인 잡을 실행하도록 구성되지 않았습니다. 이는 인스턴스가 바쁠 때, 워커가 구성된 후 몇 달 또는 몇 년이 지나 작업 부하가 변경되었거나 GitLab 제품 변경의 결과로 잡 백로그가 발생할 수 있습니다.

다음 Ruby 스크립트로 Sidekiq 워커 상태에 대한 데이터를 수집합니다.

1. 스크립트를 만듭니다:

   cat > /var/opt/gitlab/sidekiqcheck.rb <
   

2. 실행하고 출력을 캡처합니다:

   sudo gitlab-rails runner /var/opt/gitlab/sidekiqcheck.rb > /tmp/sidekiqcheck_$(date '+%Y%m%d-%H:%M').out
   

   성능 문제가 간헐적인 경우:

   • 5분마다 크론 잡으로 실행합니다. 충분한 공간이 있는 위치에 파일을 씁니다: 파일당 최소 500KB를 허용합니다.

     cat > /etc/cron.d/sidekiqcheck < /tmp/sidekiqcheck_$(date '+\%Y\%m\%d-\%H:\%M').out 2>&1
     EOF
     

   • 데이터를 참조하여 무엇이 잘못되었는지 확인합니다.

3. 출력을 분석합니다. 다음 명령은 출력 파일 디렉토리가 있다고 가정합니다.

   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개의 워커 프로세스 중 두 개만 바빴습니다.

      • 이는 다른 워커들이 너무 구체적으로 구성되어 있음을 나타냅니다.

      • 어떤 워커가 바쁜지 파악하기 위해 전체 출력을 봅니다. 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 신호에 응답할 수 없는 경우도 있습니다. 이 경우 다른 문제 해결 방법으로 넘어가세요.

rbspy를 사용한 Ruby 프로파일링#

rbspy는 Ruby 프로세스의 CPU 사용을 플레임그래프 스타일 다이어그램으로 만드는 데 사용할 수 있는 사용하기 쉽고 오버헤드가 낮은 Ruby 프로파일러입니다.

GitLab 변경이 필요 없으며 의존성도 없습니다. 설치하려면:

1. rbspy 릴리스 페이지에서 바이너리를 다운로드합니다.
2. 바이너리를 실행 가능하게 만듭니다.

Sidekiq 워커를 1분 동안 프로파일링하려면 다음을 실행합니다:

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

이 rbspy로 생성된 플레임그래프 예시에서 Sidekiq 프로세스의 시간 대부분이 Rugged의 네이티브 C 함수인 rev_parse에서 사용됩니다. 스택에서 rev_parse가 ExpirePipelineCacheWorker에 의해 호출되는 것을 볼 수 있습니다.

rbspy는 컨테이너화된 환경에서 추가 기능이 필요합니다. 최소 SYS_PTRACE 기능이 필요하며, 그렇지 않으면 permission denied 오류로 종료됩니다.

securityContext:
  capabilities:
    add:
      - SYS_PTRACE

docker run --cap-add SYS_PTRACE [...]

services:
  ruby_container_name:
    # ...
    cap_add:
      - SYS_PTRACE

perf를 사용한 프로세스 프로파일링#

Linux에는 특정 프로세스가 CPU를 많이 사용할 때 도움이 되는 perf라는 프로세스 프로파일링 도구가 있습니다. 높은 CPU 사용률이 보이고 Sidekiq이 TTIN 신호에 응답하지 않으면 이것이 좋은 다음 단계입니다.

perf가 시스템에 설치되지 않은 경우 apt-get 또는 yum으로 설치합니다:

# Debian
sudo apt-get install linux-tools

# Ubuntu (이러한 추가 Kernel 패키지가 필요할 수 있음)
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초 동안 실행한 다음 Control-C를 누릅니다. 그런 다음 perf 보고서를 봅니다:

$ sudo perf report

# 샘플 출력
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로 프로세스에 연결하면 프로세스의 표준 작동이 일시 중단됩니다(gdb가 연결된 동안 Sidekiq은 잡을 처리하지 않음).

Sidekiq PID에 연결하여 시작합니다:

gdb -p <sidekiq_pid>

그런 다음 모든 스레드에 대한 정보를 수집합니다:

info threads

# 예시 출력
30 Thread 0x7fe5fbd63700 (LWP 26060) 0x0000003f7cadf113 in poll () from /lib64/libc.so.6
29 Thread 0x7fe5f2b3b700 (LWP 26533) 0x0000003f7ce0b68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
28 Thread 0x7fe5f2a3a700 (LWP 26534) 0x0000003f7ce0ba5e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
27 Thread 0x7fe5f2939700 (LWP 26535) 0x0000003f7ce0b68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
26 Thread 0x7fe5f2838700 (LWP 26537) 0x0000003f7ce0b68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
25 Thread 0x7fe5f2737700 (LWP 26538) 0x0000003f7ce0b68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
24 Thread 0x7fe5f2535700 (LWP 26540) 0x0000003f7ce0b68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
23 Thread 0x7fe5f2434700 (LWP 26541) 0x0000003f7ce0b68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
22 Thread 0x7fe5f2232700 (LWP 26543) 0x0000003f7ce0b68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
21 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
...

예시의 Nokogiri 스레드처럼 의심스러운 스레드를 발견하면 더 많은 정보를 얻을 수 있습니다:

thread 21
bt

# 예시 출력
#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 종료 신호#

TTIN은 앞서 로깅을 위한 백트레이스를 출력하는 신호로 설명되었지만 Sidekiq은 다른 신호에도 응답합니다. 예를 들어 TSTP와 TERM을 사용하여 Sidekiq을 정상적으로 종료할 수 있으며, Sidekiq 신호 문서를 참조하세요.

차단 쿼리 확인#

Sidekiq이 잡을 처리하는 속도가 너무 빠르면 데이터베이스 경합이 발생할 수 있습니다. 앞서 설명한 백트레이스에서 많은 스레드가 데이터베이스 어댑터에 걸려 있을 때 차단 쿼리를 확인합니다.

PostgreSQL 위키에는 차단 쿼리를 보기 위해 실행할 수 있는 쿼리에 대한 세부 정보가 있습니다. 쿼리는 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는 Sidekiq 프로세스당 고유 식별자
  # thread_id는 스레드당 고유 식별자
  # work는 다음과 같은 Hash:
  # {"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')
# 이 예시에서는 ID가 125인 프로젝트와 ref `ref/heads/my_branch`에 대한
# update_merge_requests 잡을 제거합니다
queue.each { |job| job.delete if job.args[0] == 125 and job.args[4] == 'ref/heads/my_branch' }

# 다음과 같은 잡 취소: `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

특정 워커에 대한 Sidekiq 잡 제거(파괴적)#

queue = Sidekiq::Queue.new("default")

queue.each do |job|
  if job.klass == "TodosDestroyer::PrivateFeaturesWorker"
    # 실제로 잡을 삭제하려면 아래 줄의 주석을 제거합니다
    #job.delete
    puts "Deleted job ID #{job.jid}"
  end
end

실행 중인 잡 취소(파괴적)#

이는 매우 위험한 작업으로 최후의 수단으로만 사용하세요. 잡이 실행 중에 중단되고 트랜잭션의 적절한 롤백이 구현되지 않았을 수 있기 때문에 데이터 손상이 발생할 수 있습니다.

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

이는 Sidekiq이 SIDEKIQ_MONITOR_WORKER=1 환경 변수와 함께 실행될 것을 요구합니다.

인터럽트를 수행하기 위해 Thread.raise를 사용하며 이는 Why Ruby's Timeout is dangerous (and Thread.raise is terrifying)에 언급된 것처럼 여러 단점이 있습니다.

크론 잡 수동 트리거#

/admin/background_jobs를 방문하면 인스턴스에서 예약/실행/대기 중인 잡을 확인할 수 있습니다.

"지금 큐에 추가" 버튼을 선택하여 UI에서 크론 잡을 트리거할 수 있습니다. 프로그래밍 방식으로 크론 잡을 트리거하려면 먼저 Rails 콘솔을 엽니다.

테스트할 크론 잡을 찾으려면:

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

# 잡 상태 가져오기:
job.status

# 지금 바로 잡 큐에 추가!
job.enque!

예를 들어 저장소 미러를 업데이트하는 update_all_mirrors_worker 크론 잡을 트리거하려면:

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

사용 가능한 잡 목록은 workers 디렉토리에서 찾을 수 있습니다.

Sidekiq 잡에 대한 자세한 내용은 Sidekiq-cron 문서를 참조하세요.

크론 잡 비활성화#

관리자 영역의 모니터링 섹션을 방문하여 Sidekiq 크론 잡을 비활성화할 수 있습니다. 또한 명령줄과 Rails Runner를 사용하여 동일한 작업을 수행할 수 있습니다.

모든 크론 잡을 비활성화하려면:

sudo gitlab-rails runner 'Sidekiq::Cron::Job.all.map(&:disable!)'

모든 크론 잡을 활성화하려면:

sudo gitlab-rails runner 'Sidekiq::Cron::Job.all.map(&:enable!)'

한 번에 일부 잡만 활성화하려면 이름 매칭을 사용할 수 있습니다. 예를 들어 이름에 geo가 포함된 잡만 활성화하려면:

 sudo gitlab-rails runner 'Sidekiq::Cron::Job.all.select{ |j| j.name.match("geo") }.map(&:disable!)'

Sidekiq 잡 중복 제거 멱등성 키 지우기#

가끔 실행이 예상되는 잡(예: 크론 잡)이 전혀 실행되지 않는 것이 관찰됩니다. 로그를 확인하면 "job_status": "deduplicated"로 잡이 실행되지 않는 경우가 있습니다.

이는 잡이 실패하고 멱등성 키가 제대로 지워지지 않았을 때 발생할 수 있습니다. 예를 들어 Sidekiq을 중지하면 25초 후에 남은 잡이 종료됩니다.

기본적으로 키는 6시간 후에 만료됩니다. 그러나 멱등성 키를 즉시 지우려면 다음 단계를 따르세요(Geo::VerificationBatchWorker에 대한 예시 제공):

1. Sidekiq 로그에서 잡의 워커 클래스와 args를 찾습니다:

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

2. Rails 콘솔 세션을 시작합니다.

3. 다음 스니펫을 실행합니다:

   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!
   

Sidekiq BRPOP 호출로 인한 Redis CPU 포화#

Sidekiq BROP 호출은 Redis의 CPU 사용량을 증가시킬 수 있습니다. SIDEKIQ_SEMI_RELIABLE_FETCH_TIMEOUT 환경 변수를 늘려 Redis의 CPU 사용량을 개선합니다.

오류: OpenSSL::Cipher::CipherError#

다음과 같은 오류 메시지를 받으면:

"OpenSSL::Cipher::CipherError","exception.message":"","exception.backtrace":["encryptor (3.0.0) lib/encryptor.rb:98:in `final'","encryptor (3.0.0) lib/encryptor.rb:98:in `crypt'","encryptor (3.0.0) lib/encryptor.rb:49:in `decrypt'"

이 오류는 프로세스가 GitLab 데이터베이스에 저장된 암호화된 데이터를 복호화할 수 없음을 의미합니다. 이는 /etc/gitlab/gitlab-secrets.json 파일에 문제가 있음을 나타내며, 기본 GitLab 노드에서 Sidekiq 노드로 파일을 복사했는지 확인합니다.

관련 주제#

• Elasticsearch 워커가 Sidekiq을 과부하시킴.