여러 Sidekiq 프로세스 실행

단일 GitLab 인스턴스에서 여러 Sidekiq 프로세스를 실행하여 더 높은 처리율을 달성하는 방법.

GitLab은 단일 인스턴스에서 더 빠른 속도로 백그라운드 잡을 처리하기 위해 여러 Sidekiq 프로세스를 시작할 수 있습니다. 기본적으로 Sidekiq은 하나의 워커 프로세스를 시작하고 단일 CPU 코어만 사용합니다. Note 이 페이지의 정보는 Linux 패키지 설치에만 적용됩니다. 여러 프로세스 시작 # 여러 프로세스를 시작할 때 프로세스 수는 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 프로세스를 보려면: 오른쪽 상단 모서리에서 관리자 를 선택합니다. 모니터링 > 백그라운드 잡 을 선택합니다. 동시성 # 기본적으로 sidekiq 아래에 정의된 각 프로세스는 대기열 수에 1개의 여분 스레드를 더한 수(최대 50개)의 스레드로 시작합니다. 예를 들어 모든 대기열을 처리하는 프로세스는 기본적으로 50개의 스레드를 사용합니다. 이러한 스레드는 단일 Ruby 프로세스 내에서 실행되며 각 프로세스는 단일 CPU 코어만 사용할 수 있습니다. 스레딩의 유용성은 데이터베이스 쿼리나 HTTP 요청과 같이 기다려야 할 외부 의존성이 있는 작업에 달려 있습니다. 대부분의 Sidekiq 배포는 이 스레딩의 혜택을 받습니다. 데이터베이스 연결 계획 # Sidekiq 프로세스 또는 동시성을 늘리기 전에 PostgreSQL max_connections 설정에 미치는 데이터베이스 연결 영향을 고려합니다. 자세한 연결 계획 및 계산은 PostgreSQL 튜닝 페이지를 참조하세요. 스레드 수 명시적 관리 # 올바른 최대 스레드 수(동시성이라고도 함)는 워크로드에 따라 다릅니다. 일반적인 값은 CPU 집약적인 작업의 경우 5 , 혼합된 낮은 우선순위 작업의 경우 15 이상입니다. 비전문화된 배포의 합리적인 시작 범위는 15 ~ 25 입니다. 값은 Sidekiq의 각 특정 배포가 하는 작업에 따라 다릅니다. 특정 대기열 전용 프로세스가 있는 다른 전문화된 배포는 다음에 따라 동시성을 조정해야 합니다: 각 프로세스 유형의 CPU 사용량. 달성된 처리량. 각 스레드는 Redis 연결이 필요하므로 스레드를 추가하면 Redis 지연 시간이