Sidekiq 문제 해결

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

Sidekiq은 GitLab이 작업을 비동기적으로 실행하는 데 사용하는 백그라운드 job 처리기입니다. 문제가 발생하면 원인을 파악하기 어려울 수 있습니다. 프로덕션 시스템의 job 대기열이 가득 차고 있을 수 있어 이러한 상황은 높은 압박감을 주는 경향이 있습니다. 새 브랜치가 표시되지 않거나 머지 리퀘스트가 업데이트되지 않기 때문에 사용자는 이런 일이 발생하면 알아차립니다. 다음은 병목 현상을 진단하는 데 도움이 되는 몇 가지 문제 해결 단계입니다. GitLab 관리자와 사용자는 백트레이스를 GitLab 팀이 분석할 수 있도록 GitLab 지원팀과 함께 이러한 디버그 단계를 진행하는 것을 고려해야 합니다. 이를 통해 GitLab의 버그나 필요한 개선 사항이 드러날 수 있습니다. 어떤 백트레이스에서든 모든 스레드가 데이터베이스나 Redis에서 대기하거나 뮤텍스 획득을 기다리는 것처럼 보이는 경우를 의심할 때는 주의합니다. 예를 들어 이는 데이터베이스에 경합이 있다는 뜻일 수 있지만, 나머지와 다른 하나의 스레드를 찾아봅니다. 이 다른 스레드가 가용한 모든 CPU를 사용하고 있거나, 다른 스레드가 계속 실행되지 못하게 하는 Ruby Global Interpreter Lock을 보유하고 있을 수 있습니다. Sidekiq job에 전달된 인수 로깅 # Sidekiq job에 전달된 일부 인수는 기본적으로 로깅됩니다. 민감한 정보(예: 비밀번호 재설정 토큰)가 로깅되지 않도록 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