Sidekiq 문제 해결

Sidekiq 성능 문제, 대기열 백로그, 스레드 덤프, Ruby/프로세스 프로파일링, 잡 관리, 크론 잡 제어 등 Sidekiq 관련 문제를 진단하고 해결하는 방법을 설명합니다.

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_writ