여러 개의 Sidekiq 프로세스 실행

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

GitLab을 사용하면 단일 인스턴스에서 백그라운드 작업을 더 높은 속도로 처리하기 위해 여러 개의 Sidekiq 프로세스를 시작할 수 있습니다. 기본적으로 Sidekiq은 하나의 워커 프로세스를 시작하고 단일 코어만 사용합니다.

note
이 페이지의 정보는 Linux 패키지 설치에만 적용됩니다.

여러 프로세스 시작

여러 프로세스를 시작할 때는 프로세스 수를 코어에 헌신하려는 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개)와 1개의 여분 스레드로 시작합니다. 예를 들어 모든 큐를 처리하는 프로세스는 기본적으로 50개의 스레드를 사용합니다.

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

스레드 수 명시적으로 관리

올바른 최대 스레드 수(동시성이라고도 함)는 작업 부하에 따라 다릅니다. 일반적인 값은 고도로 CPU 중심적인 작업에 대해 5부터 혼합 저우선 순위 작업에 대해 15 또는 그 이상입니다. 특별화되지 않은 배포에 대한 합리적인 개시 범위는 15~25입니다.

값은 각 Sidekiq 배포가 하는 작업에 따라 다릅니다. 특정 큐에 전용된 프로세스가있는 다른 특수화된 배포, 정도에 따라 동시성을 조정해야 합니다.

  • 각 유형의 프로세스의 CPU 사용률.
  • 실현한 처리량.

각 스레드에는 Redis 연결이 필요하므로 스레드를 추가하면 Redis 대기 시간이 증가하고 클라이언트 시간 제한을 초래할 수 있습니다. 자세한 내용은 Redis 사용에 관한 Sidekiq 설명서를 참조하십시오.

동시성 필드로 스레드 수 관리

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

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

  1. /etc/gitlab/gitlab.rb를 편집합니다. 

    sidekiq['concurrency'] = 20

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

    sudo gitlab-ctl reconfigure

min_concurrency 및 max_concurrency 필드를 사용하여 스레드 수 관리(사용 중단됨)

caution
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이상으로 두십시오. 동시성은 다음과 같이 설정됩니다.

  1. min_concurrency는 max_concurrency와 동일한 경우.
  2. min_concurrency에서 max_concurrency 사이인 경우에는 N.
  3. max_concurrency를 초과하는 경우 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를 사용한 문제 해결

caution
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 프로세스의 PID가 아닌 sidekiq-cluster 명령의 PID가 포함되어 있음을 염두에 두세요.

환경

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