여러 개의 Sidekiq 프로세스 실행

Tier: Free, Premium, Ultimate Offering: Self-Managed

기본적으로 Sidekiq은 하나의 CPU 코어만 사용하는 단일 인스턴스에서 백그라운드 작업을 더 빠르게 처리하기 위해 여러 개의 Sidekiq 프로세스를 시작할 수 있습니다.

참고: 이 페이지의 정보는 리눅스 패키지 설치에만 적용됩니다.

여러 프로세스 시작

여러 프로세스를 시작할 때, 프로세스 수는 Sidekiq에 할당하려는 CPU 코어 수와 동일하거나 그 이하여야 합니다. Sidekiq 워커 프로세스는 하나의 CPU 코어를 초과하여 사용하지 않습니다.

여러 프로세스를 시작하려면 sidekiq['queue_groups'] 배열 설정을 사용하여 sidekiq-cluster를 사용하여 생성할 프로세스 수와 처리해야 하는 큐를 지정합니다. 배열의 각 항목은 하나의 추가적인 Sidekiq 프로세스에 해당하며, 각 항목의 값은 해당 큐를 처리하는 방법을 결정합니다. 대다수의 경우, 모든 프로세스가 모든 큐를 수신해야 합니다 (자세한 내용은 특정 작업 클래스 처리하기를 참조하십시오).

예를 들어, 모든 사용 가능한 큐를 수신하는 네 개의 Sidekiq 프로세스를 생성하려면:

  1. /etc/gitlab/gitlab.rb 파일을 편집합니다. 

    sidekiq['queue_groups'] = ['*'] * 4

  2. 파일을 저장하고 GitLab을 다시 구성합니다. 

    sudo gitlab-ctl reconfigure

GitLab에서 Sidekiq 프로세스를 보려면:

  1. 왼쪽 사이드바에서 맨 아래에서 관리 영역을 선택합니다.
  2. 모니터링 > 백그라운드 작업을 선택합니다.

동시성

기본적으로 sidekiq 아래에 정의된 각 프로세스는 큐 수에 따라 하나의 여분 스레드를 포함하여 최대 50까지의 스레드로 시작합니다. 예를 들어, 모든 큐를 처리하는 프로세스는 기본적으로 50개의 스레드를 사용합니다.

이러한 스레드는 단일 Ruby 프로세스 내에서 실행되며, 각 프로세스는 하나의 CPU 코어만 사용할 수 있습니다. 스레딩의 유용성은 데이터베이스 쿼리나 HTTP 요청과 같은 외부 종속성이 대기해야 하는 작업에 따라 달라집니다. 대부분의 Sidekiq 배포는 이 스레딩을 통해 이점을 얻습니다.

스레드 수 명시적으로 관리하기

올바른 최대 스레드 수(또는 동시성)는 작업에 따라 달라집니다. 고비용 CPU 작업에 대해서는 5부터 시작하여 저우선순위 작업의 경우 15 이상까지가 일반적인 값들입니다. 특수화되지 않은 배포에 대해서는 15에서 25 사이의 범위에서 시작하는 것이 합리적입니다.

각 구체적인 Sidekiq 배포에 따라 값은 근무하는 작업에 따라 다릅니다. 특정 큐에 전용 프로세스가 있는 경우 스레드 수는 다음을 기준으로 조정되어야 합니다.

  • 각 유형의 프로세스 CPU 사용량.
  • 달성된 처리량.

각 스레드는 Redis 연결이 필요하므로 스레드를 추가하면 Redis 지연이 증가할 수 있으며 클라이언트 타임아웃을 유발할 수도 있습니다. 자세한 내용은 Redis에 관한 Sidekiq 문서를 참조하십시오.

concurrency 필드로 스레드 수 관리하기

GitLab 16.9 이상에서 concurrency를 설정하여 각 프로세스의 동시성을 설정할 수 있습니다.

예를 들어, 동시성을 20으로 설정하려면:

  1. /etc/gitlab/gitlab.rb 파일을 편집합니다. 

    sidekiq['concurrency'] = 20

  2. 파일을 저장하고 GitLab을 다시 구성합니다. 

    sudo gitlab-ctl reconfigure

min_concurrency 및 max_concurrency 필드로 스레드 수 관리하기 (폐기됨)

경고: min_concurrency 및 max_concurrency 설정은 GitLab 16.9에서 폐기되었으며 17.0에서 제거될 예정입니다. 대신 concurrency를 사용하십시오.

우리는 min_concurrency 및 max_concurrency를 동일한 값으로 설정하여 명시적인 동시성을 설정하는 것을 권장합니다. 두 가지 다른 설정은 하위 호환성을 유지하기 위해 유지되었습니다. 더 예측 가능한 결과를 얻기 위해 동일한 값으로 설정하거나, 그렇지 않으면 Sidekiq 작업이 쌓이는 문제가 발생할 수 있습니다.

예를 들어, 동시성을 20으로 설정하려면:

  1. /etc/gitlab/gitlab.rb 파일을 편집합니다. 

    sidekiq['min_concurrency'] = 20
sidekiq['max_concurrency'] = 20

  2. 파일을 저장하고 GitLab을 다시 구성합니다. 

    sudo gitlab-ctl reconfigure

min_concurrency 및 max_concurrency은 독립적입니다. 하나는 다른 것을 설정할 수 있습니다. min_concurrency을 0으로 설정하면 제한이 해제됩니다. min_concurrency을 명시적으로 설정하지 않으면 0으로 설정하는 것과 같습니다.

각 큐 그룹에 대해 N은 큐 수보다 하나가 더 많습니다. 동시성은 다음과 같이 설정됩니다.

  1. min_concurrency가 max_concurrency와 동일한 경우.
  2. min_concurrency과 max_concurrency 사이인 경우는 N.
  3. N이 이 값을 초과하는 경우 max_concurrency.
  4. N이 이 값을 못 미치는 경우 min_concurrency.

min_concurrency이 max_concurrency보다 큰 경우, max_concurrency와 동일하게 취급됩니다.

체크 간격 수정하기

추가 Sidekiq 프로세스의 건강을 확인하는 Sidekiq 체크 간격을 수정하려면 다음과 같이 합니다:

  1. /etc/gitlab/gitlab.rb 파일을 편집합니다: 

    sidekiq['interval'] = 5

    값은 어떠한 정수 초 단위도 가능합니다.

  2. 파일을 저장하고 GitLab을 다시 구성합니다: 

    sudo gitlab-ctl reconfigure

CLI를 사용하여 문제 해결하기

경고: 추가 Sidekiq 프로세스를 구성하기 위해 /etc/gitlab/gitlab.rb를 사용하는 것이 권장됩니다. 문제가 발생하면 GitLab 지원팀에 문의해야 합니다. 명령줄을 사용할 때는 자기 책임하에 사용하세요.

디버깅 목적으로, 다음과 같은 구문을 사용하여 추가 Sidekiq 프로세스를 시작할 수 있습니다: /opt/gitlab/embedded/service/gitlab-rails/bin/sidekiq-cluster. 이 명령어는 다음과 같은 구문을 이용하여 인수를 받습니다: 

/opt/gitlab/embedded/service/gitlab-rails/bin/sidekiq-cluster [QUEUE,QUEUE,...] [QUEUE, ...]

--dryrun 인수를 사용하면 실제로 시작하지 않고 실행할 명령어를 확인할 수 있습니다.

각각의 별도의 인수는 Sidekiq 프로세스가 처리해야 하는 큐 그룹을 나타냅니다. 여러 큐는 공백 대신 쉼표로 구분하여 동일한 프로세스에서 처리할 수 있습니다.

큐 대신 큐 네임스페이스도 제공할 수 있으며, 이를 통해 명시적으로 모든 큐 이름을 나열하지 않아도 해당 네임스페이스의 모든 큐를 자동으로 수신하도록 처리할 수 있습니다. 큐 네임스페이스에 대한 자세한 내용은 Sidekiq 개발 문서의 관련 섹션을 참조하세요.

sidekiq-cluster 명령어 모니터링

sidekiq-cluster 명령어는 원하는 만큼의 Sidekiq 프로세스를 시작한 후에도 종료되지 않습니다. 대신, 프로세스는 계속 실행되며 어떠한 시그널도 자식 프로세스에 전달합니다. 이를 통해 개별 프로세스에 시그널을 전달하는 대신, 시그널을 sidekiq-cluster 프로세스에 전달하여 모든 Sidekiq 프로세스를 중지할 수 있습니다.

sidekiq-cluster 프로세스가 충돌하거나 SIGKILL을 받으면, 자식 프로세스는 몇 초 후에 자동으로 종료됩니다. 이를 통해 좀비 상태의 Sidekiq 프로세스가 발생하는 것을 방지합니다.

이를 통해 sidekiq-cluster를 원하는 감독자(예: runit)에 연결하여 프로세스를 모니터링할 수 있습니다.

자식 프로세스가 종료되었을 때, sidekiq-cluster 명령어는 나머지 프로세스를 종료하기 위해 시그널을 보낸 후 자체를 종료합니다. 이로써 sidekiq-cluster가 복잡한 프로세스 모니터링/재시작 코드를 다시 구현할 필요가 없어집니다. 대신, 감독자가 필요할 때마다 sidekiq-cluster를 다시 시작하도록 해야 합니다.

PID 파일

sidekiq-cluster 명령어는 PID를 파일에 저장할 수 있습니다. 기본적으로 PID 파일은 작성되지 않지만, sidekiq-cluster에 --pidfile 옵션을 전달하여 이를 변경할 수 있습니다. 예를 들어: 

/opt/gitlab/embedded/service/gitlab-rails/bin/sidekiq-cluster --pidfile /var/run/gitlab/sidekiq_cluster.pid process_commit

PID 파일에는 시작한 sidekiq-cluster 명령어의 PID가 들어있으며, 시작한 Sidekiq 프로세스의 PID가 아닙니다.

환경

Rails 환경은 sidekiq-cluster 명령어에 --environment 플래그를 전달하거나 RAILS_ENV를 비어 있지 않은 값으로 설정하여 지정할 수 있습니다. 기본값은 /opt/gitlab/etc/gitlab-rails/env/RAILS_ENV에서 찾을 수 있습니다.