여러 Sidekiq 프로세스 실행
GitLab은 단일 인스턴스에서 백그라운드 작업을 더 높은 비율로 처리하기 위해 여러 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을 선택합니다.
- Monitoring > Background jobs를 선택합니다.
동시성
기본적으로 sidekiq 아래에서 정의된 각 프로세스는 큐의 수와 같은 수의 스레드로 시작하며, 여유 스레드 하나를 포함하여 최대 50개까지 가능합니다. 예를 들어, 모든 큐를 처리하는 프로세스는 기본적으로 50개의 스레드를 사용합니다.
이 스레드는 단일 Ruby 프로세스 내에서 실행되며, 각 프로세스는 단일 CPU 코어만 사용할 수 있습니다. 스레딩의 유용성은 데이터베이스 쿼리 또는 HTTP 요청과 같은 외부 종속성을 기다리는 작업의 경우에 따라 다릅니다. 대부분의 Sidekiq 배포는 이러한 스레딩의 이점을 누립니다.
스레드 수를 명시적으로 관리
올바른 최대 스레드 수(동시성이라고도 함)는 작업 부하에 따라 달라집니다. 일반적인 값은 CPU 집약적인 작업의 경우 5에서 혼합된 저우선 작업의 경우 15 이상입니다. 비전문화된 배포의 경우 합리적인 시작 범위는 15에서 25입니다.
값은 각 특정 Sidekiq 배포에서 수행하는 작업에 따라 달라집니다. 특정 큐에 전념하는 프로세스를 가진 다른 전문화된 배포는 다음에 따라 동시성을 조정해야 합니다:
- 각 유형의 프로세스에 대한 CPU 사용량.
- 달성된 처리량.
각 스레드는 Redis 연결이 필요하므로 스레드를 추가하면 Redis 대기 시간이 증가하고 잠재적으로 클라이언트 시간 초과가 발생할 수 있습니다. 자세한 내용은 Redis에 대한 Sidekiq 문서를 참조하세요.
동시성 필드를 통해 스레드 수 관리
- GitLab 16.9에 도입됨.
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를 사용한 문제 해결
경고:
/etc/gitlab/gitlab.rb를 사용하여 Sidekiq 프로세스를 구성하는 것이 권장됩니다.
문제가 발생하면 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-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에서 확인할 수 있습니다.
도움말