여러 Sidekiq 프로세스 실행

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

GitLab에서는 단일 인스턴스에서 백그라운드 job을 더 빠르게 처리하도록 여러 Sidekiq 프로세스를 시작할 수 있습니다. 기본적으로 Sidekiq은 하나의 워커 프로세스를 시작하고 코어 하나만 사용합니다. Note 이 페이지의 내용은 Linux 패키지 설치에만 적용됩니다. 여러 프로세스 시작 # 여러 프로세스를 시작할 때 프로세스 수는 Sidekiq에 할당하려는 CPU 코어 수와 같거나 그보다 적어야 합니다. Sidekiq 워커 프로세스는 CPU 코어를 하나 넘게 사용하지 않습니다. 여러 프로세스를 시작하려면 sidekiq['queue_groups'] 배열 설정으로 sidekiq-cluster 가 만들 프로세스 수와 각 프로세스가 처리할 큐를 지정합니다. 배열의 각 항목은 추가 Sidekiq 프로세스 하나에 해당하며, 각 항목의 값이 그 프로세스가 처리할 큐를 결정합니다. 대부분의 경우 모든 프로세스가 모든 큐를 수신해야 합니다(자세한 내용은 특정 job 클래스 처리 를 참고합니다). 예를 들어 사용할 수 있는 모든 큐를 수신하는 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 배포는 이 스레딩에서 이점을 얻습니다. 데이터베이스 연결 계획 # Sidekiq 프로세스나 동시성을 늘리기 전에 PostgreSQL max_connections 설정에 미치는 데이터베이스 연결 영향을 고려합니다. 자세한 연결 계획과 계산 방법은 PostgreSQL 튜닝 페이지를 참고합니다. 스레드 수 직접 관리 # 적절한 최대 스레드 수(동시성이라고도 함)는 워크로드에 따라 다릅니다. 일반적인 값은 CPU 사용이 매우 많은 작업의 5 부터 우선순위가 낮은 혼합 작업의 15 이상까지입니다. 특화되지 않은 배포라면 15 에서 25 정도가 적절한 시작 범위입니다. 값은 각 Sidekiq 배포가 수행하는 작업에 따라 달라집니다. 특정 큐를 전담하는 프로세스를 둔 특화 배포에서는 다음을 기준으로 동시성을 조정해야 합니다: 각 프로세스 유형의 CPU 사용량입니다. 달성