여러 개의 Sidekiq 프로세스 실행
GitLab은 단일 인스턴스에서 배경 작업을 더 높은 속도로 처리하기 위해 여러 개의 Sidekiq 프로세스를 시작할 수 있습니다. 기본적으로 Sidekiq은 하나의 워커 프로세스를 시작하며 단일 코어를 사용합니다.
여러 프로세스 시작
여러 프로세스를 시작할 때, 프로세스의 수는 Sidekiq에 할당하려는 CPU 코어 수와 최대한 같거나(넘지 않게) 해야 합니다. Sidekiq 워커 프로세스는 하나의 CPU 코어 이상을 사용하지 않습니다.
여러 프로세스를 시작하려면 sidekiq['queue_groups'] 배열 설정을 사용하여 몇 개의 프로세스를 만들고 sidekiq-cluster를 사용하여 어떤 큐를 처리해야 하는지 지정하면 됩니다. 배열의 각 항목은 추가적인 Sidekiq 프로세스에 해당하며, 각 항목의 값은 해당 프로세스가 작업할 큐를 결정합니다. 대다수의 경우에 모든 프로세스가 모든 큐를 수신해야 합니다(자세한 내용은 특정 작업 클래스 처리를 참조).
예를 들어, 모든 사용 가능한 큐를 모니터링하는 네 개의 Sidekiq 프로세스를 생성하려면 다음과 같이 합니다:
-
/etc/gitlab/gitlab.rb파일 편집:sidekiq['queue_groups'] = ['*'] * 4 -
파일을 저장하고 GitLab을 다시 구성:
sudo gitlab-ctl reconfigure
GitLab에서 Sidekiq 프로세스를 보려면:
- 왼쪽 사이드바에서 아래쪽으로 이동하여 관리 영역(Admin Area)을 선택합니다.
- 모니터링(Monitoring) > 백그라운드 작업(Background Jobs)을 선택합니다.
병행성(Concurrency)
기본적으로 sidekiq 하위에 정의된 각 프로세스는 큐의 수(추가되는 예비 스레드를 포함하여 최대 50까지)와 같은 수의 스레드로 시작합니다. 예를 들어, 모든 큐를 처리하는 프로세스는 기본적으로 50개의 스레드를 사용합니다.
이러한 스레드는 하나의 Ruby 프로세스 내에서 실행되며, 각 프로세스는 하나의 CPU 코어만 사용할 수 있습니다. 스레딩의 유용성은 데이터베이스 쿼리나 HTTP 요청과 같은 외부 의존성에 대기해야 하는 작업에 달려 있습니다. 대부분의 Sidekiq 배포는 이 스레딩에서 이점을 얻습니다.
스레드 카운트 명시적으로 관리
올바른 최대 스레드 카운트(병행성이라고도 함)는 작업 부하에 달려 있습니다. 일반적인 값은 CPU에 바인드된 작업에 대해서는 5에서부터 일반적인 우선 순위가 낮은 작업에 대해서는 15 이상입니다. 특별하지 않은 배포용으로 합리적인 시작 범위는 15에서 25까지입니다.
값은 Sidekiq의 특정 배포마다 하는 작업에 따라 다릅니다. 특정 큐에 전용 프로세스가 있는 다른 특별한 배포는 각 큐에 따라 병행성을 튜닝해야 합니다:
- 각 유형의 프로세스 CPU 사용량.
- 달성된 처리량.
각 스레드는 Redis 연결이 필요하므로 스레드를 추가하면 Redis 지연이 증가할 수 있으며 클라이언트 타임아웃을 유발할 수도 있습니다. 자세한 내용은 Redis 사용에 대한 Sidekiq 문서를 참조하십시오.
concurrency 필드로 스레드 카운트 관리
- 소개 된 내용입니다.
GitLab 16.9 이상에서 concurrency를 설정하여 병행성을 설정할 수 있습니다. 이 값은 각 프로세스를 이 정도 병행성으로 명시적으로 설정합니다.
예를 들어, 병행성을 20으로 설정하려면:
-
/etc/gitlab/gitlab.rb파일 편집:sidekiq['concurrency'] = 20 -
파일을 저장하고 GitLab을 다시 구성:
sudo gitlab-ctl reconfigure
min_concurrency 및 max_concurrency 필드로 스레드 카운트 관리(폐기됨)
우리는 min_concurrency와 max_concurrency를 같은 값으로 설정하여 명시적 병행성을 설정하는 것을 권장합니다. 두 가지 다른 설정은 하위 호환성을 유지하기 위해 유지되고 있습니다. 또한 예측 가능한 결과를 위해 동일한 값으로 설정하거나, Sidekiq 작업이 쌓이는 문제를 일으킬 수 있습니다.
예를 들어, 병행성을 20으로 설정하려면:
-
/etc/gitlab/gitlab.rb파일 편집:sidekiq['min_concurrency'] = 20 sidekiq['max_concurrency'] = 20 -
파일을 저장하고 GitLab을 다시 구성:
sudo gitlab-ctl reconfigure
min_concurrency 및 max_concurrency는 독립적으로 동작하며, 한쪽을 설정하지 않으면 0으로 설정한 것과 같습니다. 또한 min_concurrency를 명시적으로 설정하지 않으면 0으로 설정한 것과 같습니다.
각 큐 그룹에 대해서 N을 큐의 수에 하나를 더한 것이라고 해둡시다. 병행성은 다음처럼 설정됩니다.
-
min_concurrency와max_concurrency가 동일한 경우. -
min_concurrency와max_concurrency사이의 값이라면,N. -
max_concurrency를 초과하면, 최대값은max_concurrency. -
min_concurrency이 값보다 작으면, 최소값은min_concurrency.
min_concurrency는 max_concurrency보다 크게 설정될 경우에는 max_concurrency와 동일하게 취급됩니다.
확인 간격 수정
추가 Sidekiq 프로세스의 Sidekiq 상태 확인 간격을 수정하려면:
-
/etc/gitlab/gitlab.rb파일 편집:sidekiq['interval'] = 5값은 어떠한 정수초로도 설정할 수 있습니다.
-
파일을 저장하고 GitLab을 다시 구성:
sudo gitlab-ctl reconfigure
CLI를 사용한 문제 해결
/etc/gitlab/gitlab.rb을 사용하는 것이 좋습니다. 문제가 발생하면 GitLab 지원팀에 문의해야 합니다. 명령줄은 사용자의 책임 하에 사용하세요.문제 해결 목적으로 /opt/gitlab/embedded/service/gitlab-rails/bin/sidekiq-cluster 명령을 사용하여 추가 Sidekiq 프로세스를 시작할 수 있습니다. 이 명령은 다음 구문을 사용하여 인수를 취합니다:
/opt/gitlab/embedded/service/gitlab-rails/bin/sidekiq-cluster [QUEUE,QUEUE,...] [QUEUE, ...]
--dryrun 인수를 사용하면 실제로 시작하지 않고 실행될 명령을 볼 수 있습니다.
각 별도의 인수는 Sidekiq 프로세스에서 처리해야 하는 큐 그룹을 나타냅니다. 여러 큐를 동일한 프로세스에서 처리하려면 공백 대신 쉼표로 구분하여 여러 큐를 처리할 수 있습니다.
큐 대신 큐 네임스페이스를 제공하여 해당 네임스페이스의 모든 큐를 명시적으로 나열할 필요 없이 프로세스가 자동으로 해당 네임스페이스의 모든 큐에서 수신되게 할 수도 있습니다. 큐 네임스페이스에 대한 자세한 내용은 Sidekiq 개발 문서의 관련 섹션을 참조하십시오 (../../development/sidekiq/index.md#queue-namespaces).
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에서 찾을 수 있습니다.
도움말