InfoGrab Docs

여러 Sidekiq 프로세스 실행

요약

GitLab은 단일 인스턴스에서 더 빠른 속도로 백그라운드 잡을 처리하기 위해 여러 Sidekiq 프로세스를 시작할 수 있습니다. 이 페이지의 정보는 Linux 패키지 설치에만 적용됩니다. 여러 프로세스를 시작할 때 프로세스 수는 Sidekiq에 할당하려는 CPU 코어 수를 최대한 초과해서는 안 됩니다.

GitLab은 단일 인스턴스에서 더 빠른 속도로 백그라운드 잡을 처리하기 위해 여러 Sidekiq 프로세스를 시작할 수 있습니다. 기본적으로 Sidekiq은 하나의 워커 프로세스를 시작하고 단일 CPU 코어만 사용합니다.

Note

이 페이지의 정보는 Linux 패키지 설치에만 적용됩니다.

여러 프로세스 시작#

여러 프로세스를 시작할 때 프로세스 수는 Sidekiq에 할당하려는 CPU 코어 수를 최대한 초과해서는 안 됩니다. Sidekiq 워커 프로세스는 하나의 CPU 코어 이상을 사용하지 않습니다.

여러 프로세스를 시작하려면 sidekiq['queue_groups'] 배열 설정을 사용하여 sidekiq-cluster를 사용하여 만들 프로세스 수와 처리해야 할 대기열을 지정합니다. 배열의 각 항목은 추가 Sidekiq 프로세스에 해당하며 각 항목의 값은 처리할 대기열을 결정합니다. 대부분의 경우 모든 프로세스는 모든 대기열을 수신해야 합니다(자세한 내용은 특정 잡 클래스 처리 참조).

예를 들어 각각 모든 사용 가능한 대기열을 수신하는 네 개의 Sidekiq 프로세스를 만들려면:

  1. /etc/gitlab/gitlab.rb를 편집합니다:

    sidekiq['queue_groups'] = ['*'] * 4

  2. 파일을 저장하고 GitLab을 재구성합니다:

    sudo gitlab-ctl reconfigure

GitLab에서 Sidekiq 프로세스를 보려면:

  1. 오른쪽 상단 모서리에서 관리자를 선택합니다.
  2. 왼쪽 사이드바에서 모니터링 > 백그라운드 잡을 선택합니다.

동시성#

기본적으로 sidekiq 아래에 정의된 각 프로세스는 대기열 수에 1개의 여분 스레드를 더한 수(최대 50개)의 스레드로 시작합니다. 예를 들어 모든 대기열을 처리하는 프로세스는 기본적으로 50개의 스레드를 사용합니다.

이러한 스레드는 단일 Ruby 프로세스 내에서 실행되며 각 프로세스는 단일 CPU 코어만 사용할 수 있습니다. 스레딩의 유용성은 데이터베이스 쿼리나 HTTP 요청과 같이 기다려야 할 외부 의존성이 있는 작업에 달려 있습니다. 대부분의 Sidekiq 배포는 이 스레딩의 혜택을 받습니다.

데이터베이스 연결 계획#

Sidekiq 프로세스 또는 동시성을 늘리기 전에 PostgreSQL max_connections 설정에 미치는 데이터베이스 연결 영향을 고려합니다.

자세한 연결 계획 및 계산은 PostgreSQL 튜닝 페이지를 참조하세요.

스레드 수 명시적 관리#

올바른 최대 스레드 수(동시성이라고도 함)는 워크로드에 따라 다릅니다. 일반적인 값은 CPU 집약적인 작업의 경우 5, 혼합된 낮은 우선순위 작업의 경우 15 이상입니다. 비전문화된 배포의 합리적인 시작 범위는 15~25입니다.

값은 Sidekiq의 각 특정 배포가 하는 작업에 따라 다릅니다. 특정 대기열 전용 프로세스가 있는 다른 전문화된 배포는 다음에 따라 동시성을 조정해야 합니다:

  • 각 프로세스 유형의 CPU 사용량.
  • 달성된 처리량.

각 스레드는 Redis 연결이 필요하므로 스레드를 추가하면 Redis 지연 시간이 증가하고 잠재적으로 클라이언트 타임아웃이 발생할 수 있습니다. 자세한 내용은 Redis에 관한 Sidekiq 문서를 참조하세요.

동시성 필드로 스레드 수 관리#

히스토리

GitLab 16.9 이상에서는 concurrency를 설정하여 동시성을 설정할 수 있습니다. 이 값은 각 프로세스를 이 동시성 양으로 명시적으로 설정합니다.

예를 들어 동시성을 20으로 설정하려면:

  1. /etc/gitlab/gitlab.rb를 편집합니다:

    sidekiq['concurrency'] = 20

  2. 파일을 저장하고 GitLab을 재구성합니다:

    sudo gitlab-ctl reconfigure

점검 간격 수정#

추가 Sidekiq 프로세스의 Sidekiq 상태 확인 간격을 수정하려면:

  1. /etc/gitlab/gitlab.rb를 편집합니다:

    sidekiq['interval'] = 5

    값은 임의의 정수 초 수일 수 있습니다.

  2. 파일을 저장하고 GitLab을 재구성합니다:

    sudo gitlab-ctl reconfigure

CLI를 사용한 트러블슈팅#

Warning

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 프로세스가 처리해야 하는 대기열 그룹을 나타냅니다. 공백 대신 쉼표로 구분하여 여러 대기열을 동일한 프로세스로 처리할 수 있습니다.

대기열 대신 대기열 네임스페이스를 제공하여 모든 대기열 이름을 명시적으로 나열하지 않고도 프로세스가 해당 네임스페이스의 모든 대기열을 자동으로 수신하도록 할 수 있습니다. 대기열 네임스페이스에 대한 자세한 내용은 GitLab 개발 문서의 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에서 찾을 수 있습니다.

여러 Sidekiq 프로세스 실행

Tier: Free, Premium, Ultimate
Offering: GitLab Self-Managed
원문 보기
요약

GitLab은 단일 인스턴스에서 더 빠른 속도로 백그라운드 잡을 처리하기 위해 여러 Sidekiq 프로세스를 시작할 수 있습니다. 이 페이지의 정보는 Linux 패키지 설치에만 적용됩니다. 여러 프로세스를 시작할 때 프로세스 수는 Sidekiq에 할당하려는 CPU 코어 수를 최대한 초과해서는 안 됩니다.

GitLab은 단일 인스턴스에서 더 빠른 속도로 백그라운드 잡을 처리하기 위해 여러 Sidekiq 프로세스를 시작할 수 있습니다. 기본적으로 Sidekiq은 하나의 워커 프로세스를 시작하고 단일 CPU 코어만 사용합니다.

Note

이 페이지의 정보는 Linux 패키지 설치에만 적용됩니다.

여러 프로세스 시작#

여러 프로세스를 시작할 때 프로세스 수는 Sidekiq에 할당하려는 CPU 코어 수를 최대한 초과해서는 안 됩니다. Sidekiq 워커 프로세스는 하나의 CPU 코어 이상을 사용하지 않습니다.

여러 프로세스를 시작하려면 sidekiq['queue_groups'] 배열 설정을 사용하여 sidekiq-cluster를 사용하여 만들 프로세스 수와 처리해야 할 대기열을 지정합니다. 배열의 각 항목은 추가 Sidekiq 프로세스에 해당하며 각 항목의 값은 처리할 대기열을 결정합니다. 대부분의 경우 모든 프로세스는 모든 대기열을 수신해야 합니다(자세한 내용은 특정 잡 클래스 처리 참조).

예를 들어 각각 모든 사용 가능한 대기열을 수신하는 네 개의 Sidekiq 프로세스를 만들려면:

  1. /etc/gitlab/gitlab.rb를 편집합니다:

    sidekiq['queue_groups'] = ['*'] * 4

  2. 파일을 저장하고 GitLab을 재구성합니다:

    sudo gitlab-ctl reconfigure

GitLab에서 Sidekiq 프로세스를 보려면:

  1. 오른쪽 상단 모서리에서 관리자를 선택합니다.
  2. 왼쪽 사이드바에서 모니터링 > 백그라운드 잡을 선택합니다.

동시성#

기본적으로 sidekiq 아래에 정의된 각 프로세스는 대기열 수에 1개의 여분 스레드를 더한 수(최대 50개)의 스레드로 시작합니다. 예를 들어 모든 대기열을 처리하는 프로세스는 기본적으로 50개의 스레드를 사용합니다.

이러한 스레드는 단일 Ruby 프로세스 내에서 실행되며 각 프로세스는 단일 CPU 코어만 사용할 수 있습니다. 스레딩의 유용성은 데이터베이스 쿼리나 HTTP 요청과 같이 기다려야 할 외부 의존성이 있는 작업에 달려 있습니다. 대부분의 Sidekiq 배포는 이 스레딩의 혜택을 받습니다.

데이터베이스 연결 계획#

Sidekiq 프로세스 또는 동시성을 늘리기 전에 PostgreSQL max_connections 설정에 미치는 데이터베이스 연결 영향을 고려합니다.

자세한 연결 계획 및 계산은 PostgreSQL 튜닝 페이지를 참조하세요.

스레드 수 명시적 관리#

올바른 최대 스레드 수(동시성이라고도 함)는 워크로드에 따라 다릅니다. 일반적인 값은 CPU 집약적인 작업의 경우 5, 혼합된 낮은 우선순위 작업의 경우 15 이상입니다. 비전문화된 배포의 합리적인 시작 범위는 15~25입니다.

값은 Sidekiq의 각 특정 배포가 하는 작업에 따라 다릅니다. 특정 대기열 전용 프로세스가 있는 다른 전문화된 배포는 다음에 따라 동시성을 조정해야 합니다:

  • 각 프로세스 유형의 CPU 사용량.
  • 달성된 처리량.

각 스레드는 Redis 연결이 필요하므로 스레드를 추가하면 Redis 지연 시간이 증가하고 잠재적으로 클라이언트 타임아웃이 발생할 수 있습니다. 자세한 내용은 Redis에 관한 Sidekiq 문서를 참조하세요.

동시성 필드로 스레드 수 관리#

히스토리

GitLab 16.9 이상에서는 concurrency를 설정하여 동시성을 설정할 수 있습니다. 이 값은 각 프로세스를 이 동시성 양으로 명시적으로 설정합니다.

예를 들어 동시성을 20으로 설정하려면:

  1. /etc/gitlab/gitlab.rb를 편집합니다:

    sidekiq['concurrency'] = 20

  2. 파일을 저장하고 GitLab을 재구성합니다:

    sudo gitlab-ctl reconfigure

점검 간격 수정#

추가 Sidekiq 프로세스의 Sidekiq 상태 확인 간격을 수정하려면:

  1. /etc/gitlab/gitlab.rb를 편집합니다:

    sidekiq['interval'] = 5

    값은 임의의 정수 초 수일 수 있습니다.

  2. 파일을 저장하고 GitLab을 재구성합니다:

    sudo gitlab-ctl reconfigure

CLI를 사용한 트러블슈팅#

Warning

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 프로세스가 처리해야 하는 대기열 그룹을 나타냅니다. 공백 대신 쉼표로 구분하여 여러 대기열을 동일한 프로세스로 처리할 수 있습니다.

대기열 대신 대기열 네임스페이스를 제공하여 모든 대기열 이름을 명시적으로 나열하지 않고도 프로세스가 해당 네임스페이스의 모든 대기열을 자동으로 수신하도록 할 수 있습니다. 대기열 네임스페이스에 대한 자세한 내용은 GitLab 개발 문서의 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에서 찾을 수 있습니다.