InfoGrab DocsInfoGrab Docs

여러 Sidekiq 프로세스 실행

요약

GitLab에서는 단일 인스턴스에서 백그라운드 job을 더 빠르게 처리하도록 여러 Sidekiq 프로세스를 시작할 수 있습니다. 이 페이지의 내용은 Linux 패키지 설치에만 적용됩니다. 여러 프로세스를 시작할 때 프로세스 수는 Sidekiq에 할당하려는 CPU 코어 수와 같거나 그보다 적어야 합니다.

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

Note

이 페이지의 내용은 Linux 패키지 설치에만 적용됩니다.

여러 프로세스 시작#

여러 프로세스를 시작할 때 프로세스 수는 Sidekiq에 할당하려는 CPU 코어 수와 같거나 그보다 적어야 합니다. Sidekiq 워커 프로세스는 CPU 코어를 하나 넘게 사용하지 않습니다.

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

예를 들어 사용할 수 있는 모든 큐를 수신하는 Sidekiq 프로세스 네 개를 만들려면 다음 단계를 따릅니다:

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

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

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

    sudo gitlab-ctl reconfigure

GitLab에서 Sidekiq 프로세스를 보려면 다음 단계를 따릅니다:

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Monitoring > Background jobs를 선택합니다.

동시성#

기본적으로 sidekiq 아래에 정의된 각 프로세스는 큐 수에 여유 스레드 하나를 더한 만큼의 스레드로 시작하며, 최대 50개까지 늘어납니다. 예를 들어 모든 큐를 처리하는 프로세스는 기본적으로 50개 스레드를 사용합니다.

이 스레드들은 하나의 Ruby 프로세스 안에서 실행되며, 각 프로세스는 CPU 코어 하나만 사용할 수 있습니다. 스레딩의 효용은 데이터베이스 쿼리나 HTTP 요청처럼 대기해야 하는 외부 의존성이 있는지에 달려 있습니다. 대부분의 Sidekiq 배포는 이 스레딩에서 이점을 얻습니다.

데이터베이스 연결 계획#

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

자세한 연결 계획과 계산 방법은 PostgreSQL 튜닝 페이지를 참고합니다.

스레드 수 직접 관리#

적절한 최대 스레드 수(동시성이라고도 함)는 워크로드에 따라 다릅니다. 일반적인 값은 CPU 사용이 매우 많은 작업의 5부터 우선순위가 낮은 혼합 작업의 15 이상까지입니다. 특화되지 않은 배포라면 15에서 25 정도가 적절한 시작 범위입니다.

값은 각 Sidekiq 배포가 수행하는 작업에 따라 달라집니다. 특정 큐를 전담하는 프로세스를 둔 특화 배포에서는 다음을 기준으로 동시성을 조정해야 합니다:

  • 각 프로세스 유형의 CPU 사용량입니다.
  • 달성한 처리량입니다.

각 스레드에는 Redis 연결이 필요하므로 스레드를 늘리면 Redis 지연 시간이 늘고 클라이언트 시간 초과가 발생할 수 있습니다. 자세한 내용은 Redis에 관한 Sidekiq 문서를 참고합니다.

concurrency 필드로 스레드 수 관리#

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 프로세스 실행

GitLab v19.5
Tier: Free, Premium, Ultimate
Offering: GitLab Self-Managed
원문 보기

요약

GitLab에서는 단일 인스턴스에서 백그라운드 job을 더 빠르게 처리하도록 여러 Sidekiq 프로세스를 시작할 수 있습니다. 이 페이지의 내용은 Linux 패키지 설치에만 적용됩니다. 여러 프로세스를 시작할 때 프로세스 수는 Sidekiq에 할당하려는 CPU 코어 수와 같거나 그보다 적어야 합니다.

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

Note

이 페이지의 내용은 Linux 패키지 설치에만 적용됩니다.

여러 프로세스 시작#

여러 프로세스를 시작할 때 프로세스 수는 Sidekiq에 할당하려는 CPU 코어 수와 같거나 그보다 적어야 합니다. Sidekiq 워커 프로세스는 CPU 코어를 하나 넘게 사용하지 않습니다.

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

예를 들어 사용할 수 있는 모든 큐를 수신하는 Sidekiq 프로세스 네 개를 만들려면 다음 단계를 따릅니다:

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

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

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

    sudo gitlab-ctl reconfigure

GitLab에서 Sidekiq 프로세스를 보려면 다음 단계를 따릅니다:

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Monitoring > Background jobs를 선택합니다.

동시성#

기본적으로 sidekiq 아래에 정의된 각 프로세스는 큐 수에 여유 스레드 하나를 더한 만큼의 스레드로 시작하며, 최대 50개까지 늘어납니다. 예를 들어 모든 큐를 처리하는 프로세스는 기본적으로 50개 스레드를 사용합니다.

이 스레드들은 하나의 Ruby 프로세스 안에서 실행되며, 각 프로세스는 CPU 코어 하나만 사용할 수 있습니다. 스레딩의 효용은 데이터베이스 쿼리나 HTTP 요청처럼 대기해야 하는 외부 의존성이 있는지에 달려 있습니다. 대부분의 Sidekiq 배포는 이 스레딩에서 이점을 얻습니다.

데이터베이스 연결 계획#

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

자세한 연결 계획과 계산 방법은 PostgreSQL 튜닝 페이지를 참고합니다.

스레드 수 직접 관리#

적절한 최대 스레드 수(동시성이라고도 함)는 워크로드에 따라 다릅니다. 일반적인 값은 CPU 사용이 매우 많은 작업의 5부터 우선순위가 낮은 혼합 작업의 15 이상까지입니다. 특화되지 않은 배포라면 15에서 25 정도가 적절한 시작 범위입니다.

값은 각 Sidekiq 배포가 수행하는 작업에 따라 달라집니다. 특정 큐를 전담하는 프로세스를 둔 특화 배포에서는 다음을 기준으로 동시성을 조정해야 합니다:

  • 각 프로세스 유형의 CPU 사용량입니다.
  • 달성한 처리량입니다.

각 스레드에는 Redis 연결이 필요하므로 스레드를 늘리면 Redis 지연 시간이 늘고 클라이언트 시간 초과가 발생할 수 있습니다. 자세한 내용은 Redis에 관한 Sidekiq 문서를 참고합니다.

concurrency 필드로 스레드 수 관리#

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에서 확인할 수 있습니다.