여러 개의 Sidekiq 프로세스 실행
GitLab을 사용하면 단일 인스턴스에서 백그라운드 작업을 더 빠르게 처리하기 위해 여러 개의 Sidekiq 프로세스를 시작할 수 있습니다. 기본적으로 Sidekiq은 한 개의 워커 프로세스를 시작하고 단일 코어만을 사용합니다.
주의: 이 페이지의 정보는 Linux 패키지 설치에만 적용됩니다.
여러 프로세스 시작
여러 프로세스를 시작할 때, 프로세스의 수는 Sidekiq에 할당하려는 CPU 코어의 수와 같거나(초과하면 안 됨) 최대로 일치해야 합니다. Sidekiq 워커 프로세스는 하나의 CPU 코어를 초과하여 사용하지 않습니다.
여러 프로세스를 시작하려면 sidekiq['queue_groups'] 배열 설정을 사용하여 sidekiq-cluster를 사용하여 생성할 프로세스의 수와 처리할 대기열을 지정합니다. 배열의 각 항목은 하나의 추가 Sidekiq 프로세스에 해당하며, 각 항목의 값은 해당 프로세스에서 처리할 대기열을 결정합니다. 대부분의 경우 모든 프로세스가 모든 대기열을 수신해야 합니다(자세한 내용은 특정 작업 클래스 처리를 참조하세요).
예를 들어, 모든 가능한 대기열을 수신하는 4개의 Sidekiq 프로세스를 만들려면:
-
/etc/gitlab/gitlab.rb를 편집하세요:sidekiq['queue_groups'] = ['*'] * 4 -
파일을 저장하고 GitLab을 다시 구성하세요:
sudo gitlab-ctl reconfigure
GitLab에서 Sidekiq 프로세스를 보려면:
- 왼쪽 사이드바에서 가장 아래에서 관리자를 선택하세요.
- 모니터링 > 백그라운드 작업을 선택하세요.
동시성
기본적으로 sidekiq에 정의된 각 프로세스는 대기열의 수와 같은 스레드 수를 갖고 시작하며, 최대 50개까지 여분의 하나의 스레드가 있습니다. 예를 들어, 모든 대기열을 처리하는 프로세스는 기본적으로 50개의 스레드를 사용합니다.
이러한 스레드는 단일 Ruby 프로세스 내에서 실행되며, 각 프로세스는 단일 CPU 코어만을 사용할 수 있습니다. 스레딩의 유용성은 데이터베이스 쿼리나 HTTP 요청과 같은 외부 종속성이 기다려야 하는 작업에 따라 다릅니다. 대부분의 Sidekiq 배포는 이러한 스레딩에서 이점을 얻습니다.
스레드 수량 명시적으로 관리
올바른 최대 스레드 수(또한 동시성이라고 함)는 작업 부하에 따라 달라집니다. 일반적인 값은 매우 CPU-바운드 작업에 대해 5부터 다양한 우선순위의 혼합 작업에 대해 15 이상입니다. 특별한 배포가 아닌 경우, 비전문적인 배포에 대한 합리적인 시작 범위는 15에서 25입니다.
이러한 값은 Sidekiq의 각 특정 배포에 따라 달라집니다. 특정 대기열에 전용 프로세스가 있는 다른 특별한 배포는 다음에 따라 동시성을 조절해야 합니다.
- 각 유형의 프로세스의 CPU 사용량.
- 달성된 처리량.
각 스레드는 Redis 연결을 필요로 하므로 스레드를 추가하면 Redis 응답 시간이 증가하고 클라이언트 타임아웃이 발생할 수 있습니다. 자세한 내용은 Redis에 대한 Sidekiq 문서를 참조하세요.
동시성 필드로 스레드 수량 관리
- [16.9(https://gitlab.com/gitlab-org/gitlab/-/issues/439687)에서 소개됨.
GitLab 16.9 이상에서 concurrency를 설정하여 동시성을 설정할 수 있습니다. 이 값은 명시적으로 각 프로세스마다 동시성을 설정합니다.
예를 들어, 동시성을 20으로 설정하려면:
-
/etc/gitlab/gitlab.rb를 편집하세요:sidekiq['concurrency'] = 20 -
파일을 저장하고 GitLab을 다시 구성하세요:
sudo gitlab-ctl reconfigure
점검 간격 수정
추가 Sidekiq 프로세스의 Sidekiq 헬스 체크 간격을 수정하려면:
-
/etc/gitlab/gitlab.rb를 편집하세요:sidekiq['interval'] = 5값은 정수 초 단위일 수 있습니다.
-
파일을 저장하고 GitLab을 다시 구성하세요:
sudo gitlab-ctl reconfigure
CLI를 사용하여 문제 해결
경고:
Sidekiq 프로세스를 구성할 때는 /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 개발 문서의 해당 섹션을 참조하세요.
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 환경은 sidekiq-cluster 명령에 --environment 플래그를 전달하거나 RAILS_ENV를 비어 있지 않은 값으로 설정하여 지정할 수 있습니다. 기본값은 /opt/gitlab/etc/gitlab-rails/env/RAILS_ENV에서 찾을 수 있습니다.
도움말