- Sidekiq 작업의 인수 로그
- Sidekiq 대기열 대기 또는 성능 저하 조사
- 스레드 덤프
rbspy를 사용한 루비 프로파일링perf로 프로세스 프로파일링하기- GNU Project Debugger인
gdb - Sidekiq kill signals
- 블로킹 쿼리 확인
- Sidekiq 대기열 관리
- 실행 중인 작업 취소 (파괴적)
- 크론 작업 수동으로 트리거
- 크론 작업 비활성화
- Sidekiq 작업 중복성 ID의 제거
- Sidekiq BRPOP 호출에 의한 Redis에서의 CPU 포화
- 관련 주제
Sidekiq 문제 해결
Sidekiq는 GitLab이 비동기적으로 작업을 실행하는 데 사용하는 백그라운드 작업 프로세서입니다. 문제가 발생하면 문제 해결이 어려울 수 있습니다. 이러한 상황은 프로덕션 시스템 작업 대기열이 채워지고 있는 경우가 많기 때문에 압박이 큽니다. 사용자들은 이런 경우를 인지할 수 있습니다. 이는 새 브랜치가 표시되지 않거나 Merge Request이 업데이트되지 않을 수 있기 때문입니다. 다음은 병목 현상을 진단하는 데 도움이 되는 몇 가지 문제 해결 단계입니다.
GitLab 관리자/사용자는 GitLab 지원팀과 함께 이러한 디버그 단계를 진행하여 백트레이스를 분석해야 합니다. 이는 버그나 GitLab의 필요한 개선 사항을 확인할 수 있습니다.
백트레이스 중 어떤 스레드가 데이터베이스, Redis를 기다리거나 뮤텍스를 획들하려고 하고 있는 경우 의심해야 합니다. 예를 들어, 데이터베이스에 충돌이 있을 수 있지만 다른 스레드가 나머지와 다른 경우를 찾아보아야 합니다. 이 다른 스레드는 모든 CPU를 사용하거나 Ruby Global Interpreter Lock를 가지고 있을 수 있으며 다른 스레드가 계속 실행되지 못하게 할 수 있습니다.
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 성능이 느린 경우 Merge Request 상태 업데이트 문제와 CI 파이프라인 실행 지연 문제가 발생할 수 있습니다.
잠재적인 원인으로는 다음이 있습니다:
-
GitLab 인스턴스에는 더 많은 Sidekiq 워커가 필요할 수 있습니다. 기본적으로 단일 노드 Linux 패키지 설치는 한 개의 워커를 실행하며 Sidekiq 작업을 최대 하나의 CPU 코어에서 실행합니다. 여러 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 작업으로 실행하세요. 충분한 공간을 가진 위치에 파일을 작성하세요. 파일당 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 -
무엇이 잘못되었는지 데이터를 확인해보세요.
-
-
출력을 분석하세요. 다음 명령어들은 출력 파일 디렉터리를 갖고 있다고 가정합니다.
-
grep 'Busy: ' *는 실행 중인 작업 수를 보여줍니다.grep 'Enqueued: ' *는 해당 시간의 작업 대기열을 보여줍니다. -
부하가 있는 스레드 수를 살펴보세요.
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)
-
파일의
---- Queues (xxx) ----섹션을 살펴보고 해당 시간에 대기 중인 작업을 확인하세요. -
파일에는 작업 중에 Sidekiq의 상태에 대한 상세 정보가 포함됩니다. 작업 부하가 일어나는 곳을 식별하는 데 유용할 수 있습니다.
-
----------- workers -----------섹션에는 요약에서Busy수를 구성하는 작업에 대한 세부 정보가 포함됩니다. -
----------- Queued Jobs -----------섹션은Enqueued상태의 작업에 대한 자세한 정보를 제공합니다.
-
-
스레드 덤프
TTIN 신호를 Sidekiq 프로세스 ID에 보내서 스레드 백트레이스를 로그 파일에 출력합니다.
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를 사용한 루비 프로파일링
rbspy는 사용하기 쉽고 오버헤드가 낮은 루비 프로파일러로, 루비 프로세스의 CPU 사용량을 Flamegraph 스타일 다이어그램으로 생성하는 데 사용할 수 있습니다.
이를 사용하기 위해 GitLab에 변경 사항은 필요하지 않으며 의존성도 없습니다. 설치 방법은 다음과 같습니다:
-
rbspy릴리스 페이지에서 바이너리를 다운로드합니다. - 해당 바이너리에 실행 권한을 부여합니다.
한 분 동안 Sidekiq 워커를 프로파일링하려면 다음을 실행하세요:
sudo ./rbspy record --pid <sidekiq_pid> --duration 60 --file /tmp/sidekiq_profile.svg
위의 rbspy가 생성한 Flamegraph 예시에서, Sidekiq 프로세스의 거의 모든 시간이 Rugged의 네이티브 C 함수인 rev_parse에서 소비되었습니다. 스택에서 ExpirePipelineCacheWorker에 의해 rev_parse가 호출되는 것을 볼 수 있습니다.
perf로 프로세스 프로파일링하기
Linux는 특정 프로세스가 많은 CPU를 소비할 때 유용한 프로세스 프로파일링 도구인 perf를 제공합니다. 높은 CPU 사용률을 볼 때 Sidekiq가 TTIN 신호에 응답하지 않는 경우에 유용합니다.
시스템에 perf가 설치되어 있지 않다면, apt-get이나 yum을 사용하여 설치하세요:
# Debian
sudo apt-get install linux-tools
# Ubuntu (추가 커널 패키지가 필요할 수 있습니다)
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
# 샘플 출력
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 리포트 샘플 출력에서 97%의 CPU가 Nokogiri와 xmlXPathNodeSetMergeAndClear에서 사용되었음을 확인할 수 있습니다. 이렇게 명백한 경우에는 해당 일이 어떤 GitLab 작업에서 사용되는지 조사해야 합니다. 이를 TTIN이나 gdb 출력과 결합하여 이러한 작업이 발생하는 해당 루비 코드를 확인하세요.
GNU Project Debugger인 gdb
gdb는 Sidekiq를 디버깅하는 또 다른 효과적인 도구입니다. 각 스레드를 상호작용적으로 살펴보고 문제의 원인을 확인할 수 있습니다.
gdb로 프로세스에 연결하면 해당 프로세스의 표준 작업이 중지됩니다(Sidekiq는 gdb가 연결된 동안 작업을 처리하지 않습니다).
먼저 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 kill signals
이전에 TTIN이 로깅을 위해 백트레이스를 출력하는 신호로 설명되었지만, Sidekiq는 다른 신호에도 응답합니다. 예를 들어 TSTP와 TERM도 Sidekiq를 정상적으로 종료하는 데 사용할 수 있습니다. 자세한 내용은 Sidekiq Signals 문서를 참조하십시오.
블로킹 쿼리 확인
가끔씩 Sidekiq가 작업을 처리하는 속도가 너무 빠르기 때문에 데이터베이스 경합을 일으킬 수 있습니다. 위의 백트레이스에서 많은 스레드가 데이터베이스 어댑터에서 막혀 있는 것으로 나타날 때 블로킹 쿼리를 확인하십시오.
PostgreSQL 위키에는 블로킹 쿼리를 확인할 수 있는 쿼리에 대한 세부 정보가 있습니다. 쿼리는 PostgreSQL 버전에 따라 다릅니다. 쿼리 세부 정보는 Lock Monitoring를 참조하십시오.
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가 제공된 모든 인수의 디렉터리이기 때문에 job.args[<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
실행 중인 작업 취소 (파괴적)
이것은 매우 위험한 작업이며 최후의 수단으로 사용해야 합니다. 작업이 실행 중인 경우 데이터 손상이 발생할 수 있으며, 작업이 실행 중일 때 트랜잭션의 적절한 롤백이 보장되지 않을 수 있습니다.
Gitlab::SidekiqDaemon::Monitor.cancel_job('job-id')
이는 Sidekiq가
SIDEKIQ_MONITOR_WORKER=1환경 변수로 실행되어야 합니다.
중단을 수행하려면 Thread.raise를 사용하는데, 이에는 루비의 Timeout이 위험하다(그리고 Thread.raise가 무서운 이유)에서 언급된 몇 가지 단점이 있습니다.
여기서 영향은 흥미롭고 무서운 부분이다. 이는 예외가 발생할 수 있음을 의미합니다:
- 네트워크 요청 중 (주변 코드가 Timeout::Error를 catch할 수 있도록 준비된 경우에만 괜찮음)
- 네트워크 요청의 정리 중
- 구조화된 예외 블록 내부
- 그 이후에 데이터베이스에 저장할 수 있는 객체를 생성 중
- 해당 코드에서 어떤 예외가 발생할 수 있는지 여부에 관계없이
누구도 어떤 라인에서든 발생할 수 있는 예외에 대비하도록 코드를 작성하지 않습니다. 그것은 심지어 불가능합니다. 그래서 Thread.raise는 사실상 코드에 대한 은밀한 공격으로 거의 모든 것을 초래할 수 있습니다. 그것은 대부분 상태를 수정하지 않는 순수 함수 코드들이었다면 괜찮았을 것입니다. 그러나 Ruby는 이것이므로 그것은 쉽지 않을 겁니다.
크론 작업 수동으로 트리거
/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')
=>
#<Sidekiq::Cron::Job:0x00007f147f84a1d0
...
irb(main):002:0> 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 작업 중복성 ID의 제거
가끔씩 실행되기로 예상된 작업(예: 크론 작업)이 전혀 실행되지 않는 것으로 관찰됩니다. 로그를 확인할 때 “job_status”: “deduplicated”“와 같이 작업이 전혀 실행되지 않는 경우가 있을 수 있습니다.
작업이 실패하고 중복성 키가 올바르게 지워지지 않은 경우가 있을 수 있습니다. 예를 들어, Sidekiq를 중지하면 25초 후에 남아있는 작업이 모두 삭제됩니다.
기본적으로 키는 6시간 후에 만료됩니다,
그러나 즉시 중복성 키를 지우려면 다음 단계를 따르세요 (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!
Sidekiq BRPOP 호출에 의한 Redis에서의 CPU 포화
Sidekiq의 BROP 호출은 Redis에서 CPU 사용량 증가를 가져올 수 있습니다.
Redis에서의 CPU 사용량을 개선하기 위해 SIDEKIQ_SEMI_RELIABLE_FETCH_TIMEOUT 환경 변수를 늘릴 수 있습니다.
도움말