InfoGrab Docs

Cgroups

요약

Linux의 컨트롤 그룹(cgroups)을 사용하여 특정 프로세스가 소비할 수 있는 메모리와 CPU 양에 제한을 가할 수 있습니다. Cgroups는 일반적으로 /sys/fs/cgroup에 마운트되는 가상 파일 시스템을 사용하여 구성되며, 계층적 방식으로 리소스를 할당합니다.

Linux의 컨트롤 그룹(cgroups)을 사용하여 특정 프로세스가 소비할 수 있는 메모리와 CPU 양에 제한을 가할 수 있습니다. Cgroups는 메모리와 CPU 과소비로 인한 예기치 않은 리소스 고갈로부터 시스템을 보호하는 데 도움이 됩니다. Cgroups는 널리 사용 가능하며 컨테이너화를 위한 기본 메커니즘으로 일반적으로 활용됩니다.

Cgroups는 일반적으로 /sys/fs/cgroup에 마운트되는 가상 파일 시스템을 사용하여 구성되며, 계층적 방식으로 리소스를 할당합니다. 마운트 포인트는 Gitaly에서 구성할 수 있습니다. 구조는 사용 중인 cgroups 버전에 따라 달라집니다:

  • Cgroups v1은 리소스 중심 계층 구조를 따릅니다. 상위 디렉토리는 cpu 및 memory와 같은 리소스입니다.
  • Cgroups v2는 프로세스 중심 방식을 채택합니다. 상위 디렉토리는 프로세스 그룹이며, 그 안의 파일들은 제어되는 각 리소스를 나타냅니다.

더 심층적인 소개는 cgroups Linux man page를 참조하세요.

Gitaly가 실행되는 경우:

  • 가상 머신에서는 cgroups v1과 cgroups v2 모두 지원됩니다. Gitaly는 마운트 포인트를 기반으로 사용할 cgroup 버전을 자동으로 감지합니다.
  • Kubernetes 클러스터에서는 cgroups v1을 사용하여 컨테이너에 cgroup 계층 구조에 대한 읽기/쓰기 권한을 위임할 수 없기 때문에 cgroups v2만 지원됩니다.

cgroups v2로 Gitaly를 실행할 때 cgroup 아래에서 프로세스를 직접 시작하기 위해 clone 시스템 호출을 사용하는 기능 등 추가 기능 및 개선 사항을 사용할 수 있습니다.

시작하기 전에#

환경에 대한 제한 활성화는 예상치 못한 트래픽으로부터 보호하는 등 특정 상황에서만 주의하여 수행해야 합니다. 제한에 도달하면 사용자에게 부정적인 영향을 미치는 연결 끊김이 발생합니다. 일관되고 안정적인 성능을 위해 먼저 노드 사양 조정이나 대형 저장소 검토 또는 워크로드와 같은 다른 옵션을 탐색해야 합니다.

메모리에 대한 cgroups를 활성화할 때는 Gitaly 노드에 스왑이 구성되어 있지 않은지 확인해야 합니다. 프로세스가 종료되는 대신 스왑을 사용하도록 전환할 수 있기 때문입니다. 커널은 사용 가능한 스왑 메모리를 cgroup이 부과한 제한에 추가적인 것으로 간주합니다. 이 상황은 성능을 현저하게 저하시킬 수 있습니다. Gitaly에서 cgroups를 활성화하려면 repositories 필드를 count가 0보다 크게 구성해야 합니다.

Gitaly가 cgroups에서 얻는 이점#

일부 Git 작업은 다음과 같은 상황에서 리소스를 과도하게 소비하여 고갈 지점까지 이를 수 있습니다:

  • 예상치 못한 높은 트래픽.
  • 모범 사례를 따르지 않는 대형 저장소에 대한 작업 실행.

이러한 리소스를 소비하는 특정 저장소의 활동은 "시끄러운 이웃(noisy neighbors)"으로 알려져 있으며, Gitaly 서버에 호스팅된 다른 저장소의 Git 성능 저하를 초래할 수 있습니다.

강력한 보호 수단으로서, Gitaly는 cgroups를 사용하여 이러한 작업이 모든 시스템 리소스를 독점하고 불안정성을 유발하기 전에 커널이 종료하도록 지시할 수 있습니다. Gitaly는 Git 명령이 작동하는 저장소를 기반으로 Git 프로세스를 cgroup에 할당합니다. 이러한 cgroups를 저장소 cgroups라고 합니다. 각 저장소 cgroup은:

  • 메모리 및 CPU 제한이 있습니다.
  • 하나 이상의 저장소에 대한 Git 프로세스를 포함합니다. 총 cgroups 수는 구성 가능합니다. 각 cgroup은 일관된 순환 해시를 사용하여 특정 저장소의 Git 프로세스가 항상 동일한 cgroup에 배치되도록 합니다.

저장소 cgroup이 다음에 도달하면:

  • 메모리 제한에 도달하면 커널이 프로세스 중에서 종료할 후보를 찾아 클라이언트 요청이 중단될 수 있습니다.
  • CPU 제한에 도달하면 프로세스가 종료되지 않지만 허용된 것보다 더 많은 CPU를 소비하는 것이 방지되어 클라이언트 요청이 스로틀될 수 있지만 중단되지는 않습니다.

이러한 제한에 도달하면 성능이 저하되고 사용자가 연결 끊김을 경험할 수 있습니다.

다음 다이어그램은 cgroup 구조를 보여줍니다:

  • 상위 cgroup은 모든 Git 프로세스에 대한 제한을 관리합니다.
  • 각 저장소 cgroup(repos-1에서 repos-3으로 명명됨)은 저장소 수준에서 제한을 적용합니다.

Gitaly 스토리지가 다음을 제공하는 경우:

  • 세 개의 저장소만 있으면 각 저장소가 cgroup 중 하나에 직접 배치됩니다.
  • 저장소 cgroups 수보다 더 많은 경우 일관된 방식으로 여러 저장소가 동일한 그룹에 할당됩니다.
Mermaid 다이어그램 (13줄)
소스 코드 보기
%%{init: { "fontFamily": "GitLab Sans" }}%%
flowchart TB
    accTitle: Gitaly cgroups structure
    accDescr: Hierarchical cgroup structure with three repository cgroups under a parent cgroup.

parent
repos-1
repos-2
repos-3


parent-->repos-1
parent-->repos-2
parent-->repos-3

초과 구독 구성#

저장소 cgroups 수는 수천 개의 저장소를 제공하는 스토리지에서도 격리가 발생할 수 있도록 충분히 높아야 합니다. 저장소 수의 좋은 시작점은 스토리지의 활성 저장소 수의 두 배입니다.

저장소 cgroups는 상위 cgroup 위에 추가 제한을 적용하기 때문에, 상위 제한을 그룹 수로 나누어 구성하면 지나치게 제한적인 한도가 됩니다. 예를 들어:

  • 상위 메모리 제한이 32 GiB입니다.
  • 활성 저장소가 약 100개 있습니다.
  • cgroups.repositories.count = 100으로 구성했습니다.

32 GiB를 100으로 나누면 저장소 cgroup당 겨우 0.32 GiB만 할당됩니다. 이 설정은 극도로 나쁜 성능과 현저한 활용 저하를 초래합니다.

초과 구독을 사용하여 정상 운영 중 기본 성능 수준을 유지하면서, 소수의 고부하 저장소가 관련 없는 요청에 영향을 미치지 않고 필요할 때 "버스트"할 수 있도록 허용할 수 있습니다. 초과 구독은 시스템에서 기술적으로 사용 가능한 것보다 더 많은 리소스를 할당하는 것을 말합니다.

이전 예제를 사용하면, 시스템에 10 GiB * 100의 시스템 메모리가 없음에도 불구하고 각각 10 GiB의 메모리를 할당하여 저장소 cgroups를 초과 구독할 수 있습니다. 이 값들은 10 GiB가 저장소에 대한 정상 작업에 충분하지만, 두 저장소가 각각 10 GiB까지 버스트하면서 세 번째 리소스 버킷이 기본 성능을 유지할 수 있게 해줍니다.

CPU 시간에도 유사한 규칙이 적용됩니다. 전체 시스템에 사용 가능한 것보다 더 많은 CPU 코어를 저장소 cgroups에 의도적으로 할당합니다. 예를 들어, 시스템에 총 400개의 코어가 없더라도 저장소 cgroup당 4개의 코어를 할당하도록 결정할 수 있습니다.

두 가지 주요 값이 초과 구독을 제어합니다:

-cpu_quota_us -memory_bytes

상위 cgroups 대비 저장소 cgroups의 각 값 차이가 초과 구독의 양을 결정합니다.

측정 및 조정#

초과 구독을 위한 올바른 기준 리소스 요구 사항을 설정하고 조정하려면 Gitaly 서버의 프로덕션 워크로드를 관찰해야 합니다. 기본적으로 노출되는 Prometheus 메트릭이 이를 위해 충분합니다. 특정 Gitaly 서버의 CPU 및 메모리 사용량을 측정하기 위한 가이드로 다음 쿼리를 사용할 수 있습니다:

쿼리 리소스
quantile_over_time(0.99, instance:node_cpu_utilization:ratio{type="gitaly", fqdn="gitaly.internal"}[5m]) 지정된 fqdn을 가진 Gitaly 노드의 p99 CPU 활용률
quantile_over_time(0.99, instance:node_memory_utilization:ratio{type="gitaly", fqdn="gitaly.internal"}[5m]) 지정된 fqdn을 가진 Gitaly 노드의 p99 메모리 활용률

대표적인 기간(예: 일반적인 업무 주) 동안 관찰한 활용률을 기반으로 정상 운영을 위한 기준 리소스 요구 사항을 결정할 수 있습니다. 이전 예제의 구성을 도출하기 위해 업무 주 동안 지속적인 10 GiB 메모리 사용량과 CPU에 4코어 부하를 관찰했을 것입니다.

워크로드가 변경됨에 따라 메트릭을 재검토하고 cgroups 구성을 조정해야 합니다. cgroups를 활성화한 후 성능이 현저하게 저하되는 경우 cgroups 구성을 조정해야 합니다. 이는 너무 제한적인 한도의 지표일 수 있습니다.

사용 가능한 구성 설정#

히스토리
  • max_cgroups_per_repo가 GitLab 16.7에서 도입되었습니다.
  • 레거시 방법에 대한 문서가 GitLab 17.8에서 제거되었습니다.

Gitaly에서 저장소 cgroups를 구성하려면 /etc/gitlab/gitlab.rb의 gitaly['configuration'][:cgroups]에 다음 설정을 사용하세요:

  • mountpoint는 상위 cgroup 디렉토리가 마운트되는 위치입니다. 기본값은 /sys/fs/cgroup입니다.
  • hierarchy_root는 Gitaly가 그룹을 생성하는 상위 cgroup으로, Gitaly가 실행되는 사용자와 그룹이 소유해야 합니다. Linux 패키지 설치는 Gitaly가 시작될 때 mountpoint/<cpu|memory>/hierarchy_root 디렉토리 세트를 생성합니다.
  • memory_bytes는 Gitaly가 생성하는 모든 Git 프로세스에 집합적으로 부과되는 총 메모리 제한입니다. 0은 제한 없음을 의미합니다.
  • cpu_shares는 Gitaly가 생성하는 모든 Git 프로세스에 집합적으로 부과되는 CPU 제한입니다. 0은 제한 없음을 의미합니다. 최대값은 1024 shares로, CPU의 100%를 나타냅니다.
  • cpu_quota_us는 프로세스가 이 할당량 값을 초과하면 cgroups 프로세스를 스로틀하기 위한 cfs_quota_us입니다. cfs_period_us를 100ms로 설정하므로 1코어는 100000입니다. 0은 제한 없음을 의미합니다.
  • repositories.count는 cgroups 풀의 cgroup 수입니다. 새 Git 명령이 생성될 때마다 Gitaly는 명령이 실행되는 저장소를 기반으로 이러한 cgroups 중 하나에 할당합니다. 순환 해싱 알고리즘이 Git 명령을 이러한 cgroups에 할당하므로 저장소의 Git 명령은 항상 동일한 cgroup에 할당됩니다.
  • repositories.memory_bytes는 저장소 cgroup에 포함된 모든 Git 프로세스에 부과되는 총 메모리 제한입니다. 0은 제한 없음을 의미합니다. 이 값은 최상위 memory_bytes를 초과할 수 없습니다.
  • repositories.cpu_shares는 저장소 cgroup에 포함된 모든 Git 프로세스에 부과되는 CPU 제한입니다. 0은 제한 없음을 의미합니다. 최대값은 1024 shares로, CPU의 100%를 나타냅니다. 이 값은 최상위 cpu_shares를 초과할 수 없습니다.
  • repositories.cpu_quota_us는 저장소 cgroup에 포함된 모든 Git 프로세스에 부과되는 cfs_quota_us입니다. Git 프로세스는 주어진 할당량보다 더 많이 사용할 수 없습니다. cfs_period_us를 100ms로 설정하므로 1코어는 100000입니다. 0은 제한 없음을 의미합니다.
  • repositories.max_cgroups_per_repo는 특정 저장소를 대상으로 하는 Git 프로세스가 분산될 수 있는 저장소 cgroups 수입니다. 이를 통해 버스트 워크로드를 허용하면서도 저장소 cgroups에 대해 보다 보수적인 CPU 및 메모리 제한을 구성할 수 있습니다. 예를 들어, max_cgroups_per_repo가 2이고 memory_bytes 제한이 10 GB인 경우 특정 저장소에 대한 독립적인 Git 작업이 최대 20 GB의 메모리를 소비할 수 있습니다.

예시(반드시 권장 설정은 아님):

# in /etc/gitlab/gitlab.rb
gitaly['configuration'] = {
  # ...
  cgroups: {
    mountpoint: '/sys/fs/cgroup',
    hierarchy_root: 'gitaly',
    memory_bytes: 64424509440, # 60 GB
    cpu_shares: 1024,
    cpu_quota_us: 400000 # 4 cores
    repositories: {
      count: 1000,
      memory_bytes: 32212254720, # 20 GB
      cpu_shares: 512,
      cpu_quota_us: 200000, # 2 cores
      max_cgroups_per_repo: 2
    },
  },
}

cgroups 모니터링#

cgroups 모니터링에 대한 정보는 Gitaly cgroups 모니터링을 참조하세요.

Cgroups

원문 보기
요약

Linux의 컨트롤 그룹(cgroups)을 사용하여 특정 프로세스가 소비할 수 있는 메모리와 CPU 양에 제한을 가할 수 있습니다. Cgroups는 일반적으로 /sys/fs/cgroup에 마운트되는 가상 파일 시스템을 사용하여 구성되며, 계층적 방식으로 리소스를 할당합니다.

Linux의 컨트롤 그룹(cgroups)을 사용하여 특정 프로세스가 소비할 수 있는 메모리와 CPU 양에 제한을 가할 수 있습니다. Cgroups는 메모리와 CPU 과소비로 인한 예기치 않은 리소스 고갈로부터 시스템을 보호하는 데 도움이 됩니다. Cgroups는 널리 사용 가능하며 컨테이너화를 위한 기본 메커니즘으로 일반적으로 활용됩니다.

Cgroups는 일반적으로 /sys/fs/cgroup에 마운트되는 가상 파일 시스템을 사용하여 구성되며, 계층적 방식으로 리소스를 할당합니다. 마운트 포인트는 Gitaly에서 구성할 수 있습니다. 구조는 사용 중인 cgroups 버전에 따라 달라집니다:

  • Cgroups v1은 리소스 중심 계층 구조를 따릅니다. 상위 디렉토리는 cpu 및 memory와 같은 리소스입니다.
  • Cgroups v2는 프로세스 중심 방식을 채택합니다. 상위 디렉토리는 프로세스 그룹이며, 그 안의 파일들은 제어되는 각 리소스를 나타냅니다.

더 심층적인 소개는 cgroups Linux man page를 참조하세요.

Gitaly가 실행되는 경우:

  • 가상 머신에서는 cgroups v1과 cgroups v2 모두 지원됩니다. Gitaly는 마운트 포인트를 기반으로 사용할 cgroup 버전을 자동으로 감지합니다.
  • Kubernetes 클러스터에서는 cgroups v1을 사용하여 컨테이너에 cgroup 계층 구조에 대한 읽기/쓰기 권한을 위임할 수 없기 때문에 cgroups v2만 지원됩니다.

cgroups v2로 Gitaly를 실행할 때 cgroup 아래에서 프로세스를 직접 시작하기 위해 clone 시스템 호출을 사용하는 기능 등 추가 기능 및 개선 사항을 사용할 수 있습니다.

시작하기 전에#

환경에 대한 제한 활성화는 예상치 못한 트래픽으로부터 보호하는 등 특정 상황에서만 주의하여 수행해야 합니다. 제한에 도달하면 사용자에게 부정적인 영향을 미치는 연결 끊김이 발생합니다. 일관되고 안정적인 성능을 위해 먼저 노드 사양 조정이나 대형 저장소 검토 또는 워크로드와 같은 다른 옵션을 탐색해야 합니다.

메모리에 대한 cgroups를 활성화할 때는 Gitaly 노드에 스왑이 구성되어 있지 않은지 확인해야 합니다. 프로세스가 종료되는 대신 스왑을 사용하도록 전환할 수 있기 때문입니다. 커널은 사용 가능한 스왑 메모리를 cgroup이 부과한 제한에 추가적인 것으로 간주합니다. 이 상황은 성능을 현저하게 저하시킬 수 있습니다. Gitaly에서 cgroups를 활성화하려면 repositories 필드를 count가 0보다 크게 구성해야 합니다.

Gitaly가 cgroups에서 얻는 이점#

일부 Git 작업은 다음과 같은 상황에서 리소스를 과도하게 소비하여 고갈 지점까지 이를 수 있습니다:

  • 예상치 못한 높은 트래픽.
  • 모범 사례를 따르지 않는 대형 저장소에 대한 작업 실행.

이러한 리소스를 소비하는 특정 저장소의 활동은 "시끄러운 이웃(noisy neighbors)"으로 알려져 있으며, Gitaly 서버에 호스팅된 다른 저장소의 Git 성능 저하를 초래할 수 있습니다.

강력한 보호 수단으로서, Gitaly는 cgroups를 사용하여 이러한 작업이 모든 시스템 리소스를 독점하고 불안정성을 유발하기 전에 커널이 종료하도록 지시할 수 있습니다. Gitaly는 Git 명령이 작동하는 저장소를 기반으로 Git 프로세스를 cgroup에 할당합니다. 이러한 cgroups를 저장소 cgroups라고 합니다. 각 저장소 cgroup은:

  • 메모리 및 CPU 제한이 있습니다.
  • 하나 이상의 저장소에 대한 Git 프로세스를 포함합니다. 총 cgroups 수는 구성 가능합니다. 각 cgroup은 일관된 순환 해시를 사용하여 특정 저장소의 Git 프로세스가 항상 동일한 cgroup에 배치되도록 합니다.

저장소 cgroup이 다음에 도달하면:

  • 메모리 제한에 도달하면 커널이 프로세스 중에서 종료할 후보를 찾아 클라이언트 요청이 중단될 수 있습니다.
  • CPU 제한에 도달하면 프로세스가 종료되지 않지만 허용된 것보다 더 많은 CPU를 소비하는 것이 방지되어 클라이언트 요청이 스로틀될 수 있지만 중단되지는 않습니다.

이러한 제한에 도달하면 성능이 저하되고 사용자가 연결 끊김을 경험할 수 있습니다.

다음 다이어그램은 cgroup 구조를 보여줍니다:

  • 상위 cgroup은 모든 Git 프로세스에 대한 제한을 관리합니다.
  • 각 저장소 cgroup(repos-1에서 repos-3으로 명명됨)은 저장소 수준에서 제한을 적용합니다.

Gitaly 스토리지가 다음을 제공하는 경우:

  • 세 개의 저장소만 있으면 각 저장소가 cgroup 중 하나에 직접 배치됩니다.
  • 저장소 cgroups 수보다 더 많은 경우 일관된 방식으로 여러 저장소가 동일한 그룹에 할당됩니다.
Mermaid 다이어그램 (13줄)
소스 코드 보기
%%{init: { "fontFamily": "GitLab Sans" }}%%
flowchart TB
    accTitle: Gitaly cgroups structure
    accDescr: Hierarchical cgroup structure with three repository cgroups under a parent cgroup.

parent
repos-1
repos-2
repos-3


parent-->repos-1
parent-->repos-2
parent-->repos-3

초과 구독 구성#

저장소 cgroups 수는 수천 개의 저장소를 제공하는 스토리지에서도 격리가 발생할 수 있도록 충분히 높아야 합니다. 저장소 수의 좋은 시작점은 스토리지의 활성 저장소 수의 두 배입니다.

저장소 cgroups는 상위 cgroup 위에 추가 제한을 적용하기 때문에, 상위 제한을 그룹 수로 나누어 구성하면 지나치게 제한적인 한도가 됩니다. 예를 들어:

  • 상위 메모리 제한이 32 GiB입니다.
  • 활성 저장소가 약 100개 있습니다.
  • cgroups.repositories.count = 100으로 구성했습니다.

32 GiB를 100으로 나누면 저장소 cgroup당 겨우 0.32 GiB만 할당됩니다. 이 설정은 극도로 나쁜 성능과 현저한 활용 저하를 초래합니다.

초과 구독을 사용하여 정상 운영 중 기본 성능 수준을 유지하면서, 소수의 고부하 저장소가 관련 없는 요청에 영향을 미치지 않고 필요할 때 "버스트"할 수 있도록 허용할 수 있습니다. 초과 구독은 시스템에서 기술적으로 사용 가능한 것보다 더 많은 리소스를 할당하는 것을 말합니다.

이전 예제를 사용하면, 시스템에 10 GiB * 100의 시스템 메모리가 없음에도 불구하고 각각 10 GiB의 메모리를 할당하여 저장소 cgroups를 초과 구독할 수 있습니다. 이 값들은 10 GiB가 저장소에 대한 정상 작업에 충분하지만, 두 저장소가 각각 10 GiB까지 버스트하면서 세 번째 리소스 버킷이 기본 성능을 유지할 수 있게 해줍니다.

CPU 시간에도 유사한 규칙이 적용됩니다. 전체 시스템에 사용 가능한 것보다 더 많은 CPU 코어를 저장소 cgroups에 의도적으로 할당합니다. 예를 들어, 시스템에 총 400개의 코어가 없더라도 저장소 cgroup당 4개의 코어를 할당하도록 결정할 수 있습니다.

두 가지 주요 값이 초과 구독을 제어합니다:

-cpu_quota_us -memory_bytes

상위 cgroups 대비 저장소 cgroups의 각 값 차이가 초과 구독의 양을 결정합니다.

측정 및 조정#

초과 구독을 위한 올바른 기준 리소스 요구 사항을 설정하고 조정하려면 Gitaly 서버의 프로덕션 워크로드를 관찰해야 합니다. 기본적으로 노출되는 Prometheus 메트릭이 이를 위해 충분합니다. 특정 Gitaly 서버의 CPU 및 메모리 사용량을 측정하기 위한 가이드로 다음 쿼리를 사용할 수 있습니다:

쿼리 리소스
quantile_over_time(0.99, instance:node_cpu_utilization:ratio{type="gitaly", fqdn="gitaly.internal"}[5m]) 지정된 fqdn을 가진 Gitaly 노드의 p99 CPU 활용률
quantile_over_time(0.99, instance:node_memory_utilization:ratio{type="gitaly", fqdn="gitaly.internal"}[5m]) 지정된 fqdn을 가진 Gitaly 노드의 p99 메모리 활용률

대표적인 기간(예: 일반적인 업무 주) 동안 관찰한 활용률을 기반으로 정상 운영을 위한 기준 리소스 요구 사항을 결정할 수 있습니다. 이전 예제의 구성을 도출하기 위해 업무 주 동안 지속적인 10 GiB 메모리 사용량과 CPU에 4코어 부하를 관찰했을 것입니다.

워크로드가 변경됨에 따라 메트릭을 재검토하고 cgroups 구성을 조정해야 합니다. cgroups를 활성화한 후 성능이 현저하게 저하되는 경우 cgroups 구성을 조정해야 합니다. 이는 너무 제한적인 한도의 지표일 수 있습니다.

사용 가능한 구성 설정#

히스토리
  • max_cgroups_per_repo가 GitLab 16.7에서 도입되었습니다.
  • 레거시 방법에 대한 문서가 GitLab 17.8에서 제거되었습니다.

Gitaly에서 저장소 cgroups를 구성하려면 /etc/gitlab/gitlab.rb의 gitaly['configuration'][:cgroups]에 다음 설정을 사용하세요:

  • mountpoint는 상위 cgroup 디렉토리가 마운트되는 위치입니다. 기본값은 /sys/fs/cgroup입니다.
  • hierarchy_root는 Gitaly가 그룹을 생성하는 상위 cgroup으로, Gitaly가 실행되는 사용자와 그룹이 소유해야 합니다. Linux 패키지 설치는 Gitaly가 시작될 때 mountpoint/<cpu|memory>/hierarchy_root 디렉토리 세트를 생성합니다.
  • memory_bytes는 Gitaly가 생성하는 모든 Git 프로세스에 집합적으로 부과되는 총 메모리 제한입니다. 0은 제한 없음을 의미합니다.
  • cpu_shares는 Gitaly가 생성하는 모든 Git 프로세스에 집합적으로 부과되는 CPU 제한입니다. 0은 제한 없음을 의미합니다. 최대값은 1024 shares로, CPU의 100%를 나타냅니다.
  • cpu_quota_us는 프로세스가 이 할당량 값을 초과하면 cgroups 프로세스를 스로틀하기 위한 cfs_quota_us입니다. cfs_period_us를 100ms로 설정하므로 1코어는 100000입니다. 0은 제한 없음을 의미합니다.
  • repositories.count는 cgroups 풀의 cgroup 수입니다. 새 Git 명령이 생성될 때마다 Gitaly는 명령이 실행되는 저장소를 기반으로 이러한 cgroups 중 하나에 할당합니다. 순환 해싱 알고리즘이 Git 명령을 이러한 cgroups에 할당하므로 저장소의 Git 명령은 항상 동일한 cgroup에 할당됩니다.
  • repositories.memory_bytes는 저장소 cgroup에 포함된 모든 Git 프로세스에 부과되는 총 메모리 제한입니다. 0은 제한 없음을 의미합니다. 이 값은 최상위 memory_bytes를 초과할 수 없습니다.
  • repositories.cpu_shares는 저장소 cgroup에 포함된 모든 Git 프로세스에 부과되는 CPU 제한입니다. 0은 제한 없음을 의미합니다. 최대값은 1024 shares로, CPU의 100%를 나타냅니다. 이 값은 최상위 cpu_shares를 초과할 수 없습니다.
  • repositories.cpu_quota_us는 저장소 cgroup에 포함된 모든 Git 프로세스에 부과되는 cfs_quota_us입니다. Git 프로세스는 주어진 할당량보다 더 많이 사용할 수 없습니다. cfs_period_us를 100ms로 설정하므로 1코어는 100000입니다. 0은 제한 없음을 의미합니다.
  • repositories.max_cgroups_per_repo는 특정 저장소를 대상으로 하는 Git 프로세스가 분산될 수 있는 저장소 cgroups 수입니다. 이를 통해 버스트 워크로드를 허용하면서도 저장소 cgroups에 대해 보다 보수적인 CPU 및 메모리 제한을 구성할 수 있습니다. 예를 들어, max_cgroups_per_repo가 2이고 memory_bytes 제한이 10 GB인 경우 특정 저장소에 대한 독립적인 Git 작업이 최대 20 GB의 메모리를 소비할 수 있습니다.

예시(반드시 권장 설정은 아님):

# in /etc/gitlab/gitlab.rb
gitaly['configuration'] = {
  # ...
  cgroups: {
    mountpoint: '/sys/fs/cgroup',
    hierarchy_root: 'gitaly',
    memory_bytes: 64424509440, # 60 GB
    cpu_shares: 1024,
    cpu_quota_us: 400000 # 4 cores
    repositories: {
      count: 1000,
      memory_bytes: 32212254720, # 20 GB
      cpu_shares: 512,
      cpu_quota_us: 200000, # 2 cores
      max_cgroups_per_repo: 2
    },
  },
}

cgroups 모니터링#

cgroups 모니터링에 대한 정보는 Gitaly cgroups 모니터링을 참조하세요.