- 제한된 환경을 위한 최소 요구 사항
- 시스템 성능 유효성 검사
- 스왑 구성
- GitLab 설치
- Puma 최적화
- Sidekiq 최적화
- Gitaly 최적화
- 모니터링 비활성화
- GitLab 메모리 처리 방법 구성
- 추가 내부 모니터링 비활성화
- 변경 사항이 포함된 구성
- 성능 결과
메모리 제한 환경에서 GitLab 실행하기
GitLab은 모든 기능이 활성화된 상태에서 실행할 때 상당량의 메모리를 필요로 합니다. GitLab을 모든 기능이 필요하지 않은 작은 설치 환경에서 실행하는 경우 등 여러 사용 사례가 있습니다. 예시로는 다음과 같은 경우가 있습니다:
- 개인용이나 매우 작은 팀을 위해 GitLab 실행
- 비용 절감을 위해 클라우드 제공 업체에서 작은 인스턴스 사용
- Raspberry PI와 같은 자원 제한 장치 사용
일부 조정을 통해 GitLab을 최소 요구 사항에 설명된 것보다 낮은 사양에서도 편안하게 실행할 수 있습니다.(최소 요구 사항 및 참조 아키텍처 참조)
다음 섹션에는 최소 요구 사항을 충족하지 못하는 환경에서 GitLab을 실행할 수 있도록 하는 권장 사항이 포함되어 있습니다. 대부분의 GitLab 구성 요소는 이러한 설정이 적용된 상태에서 정상적으로 작동해야 하지만, 제품 기능 및 성능의 예상치 못한 저하가 발생할 수 있습니다. 100MB보다 크지 않은 개별 Git 프로젝트를 가진 최대 5명의 개발자로 GitLab을 실행할 수 있어야 합니다.
제한된 환경을 위한 최소 요구 사항
GitLab을 실행할 수 있는 최소 예상 사양은 다음과 같습니다:
- Linux 기반 시스템 (이상적으로 Debian 기반 또는 RedHat 기반)
- ARM7/ARM64 4개의 CPU 코어 또는 AMD64 아키텍처 1개의 CPU 코어
- 최소 2GB RAM + 1GB 스왑, 권장 사항은 2.5GB RAM + 1GB 스왑
- 사용 가능한 저장 공간 20GB
- D 및 DQ를 선택하여 잘 작동하는 저장 장치:
위 목록 중 CPU의 단일 코어 성능 및 저장 장치의 무작위 I/O 성능이 가장 큰 영향을 미칩니다. 저장 공간은 특히 제한된 환경에서 일부 메모리 교체가 발생할 것을 예상하기 때문에 중요합니다. 작은 플랫폼의 제한된 성능의 공통 문제 중 하나는 매우 느린 디스크 저장 공간으로, 이는 시스템 전체적으로 병목 현상을 야기시킵니다.
위 최소 설정을 사용하면 시스템은 정상적인 운영 중에 스왑을 사용해야 합니다. 모든 구성 요소가 동시에 사용되지는 않기 때문에 합리적인 성능을 제공해야 합니다.
시스템 성능 유효성 검사
Linux 기반 시스템의 성능을 확인할 수 있는 다양한 도구가 있습니다. 시스템 성능을 확인하는 데 도움이 되는 프로젝트 중 하나는 sbc-bench입니다. 이는 임베디드 시스템에서 GitLab을 실행할 때 특히 중요한 시스템 테스트 모든 주의 사항과 다른 동작들이 시스템 성능에 미치는 영향을 설명합니다. 이 프로젝트는 시스템의 성능이 제한된 환경에서 GitLab을 실행하기에 충분한지 유효성을 검사하는 방법으로 사용할 수 있습니다.
다음 시스템은 GitLab의 작은 설치를 실행하는 데 적합한 성능을 제공합니다:
스왑 구성
GitLab을 설치하기 전에 스왑을 구성해야 합니다. 스왑은 물리적 RAM이 가득 찰 때 사용되는 디스크의 전용 공간입니다. Linux 시스템에서 RAM이 부족해지면 비활성 페이지는 RAM에서 스왑 공간으로 이동됩니다.
스왑 사용은 대부분 지연 시간을 증가시킬 수 있어 문제로 여겨집니다. 그러나 GitLab의 작동 방식으로 인해 할당된 메모리 중 많은 부분이 빈번하게 액세스되지 않습니다. 스왑 사용을 허용함으로써 응용 프로그램은 정상적으로 실행되고 기능을 정상적으로 수행하며 필요한 경우에만 스왑을 사용할 수 있습니다.
일반적인 지침은 사용 가능한 메모리의 약 50% 정도의 크기로 스왑을 구성하는 것입니다. 메모리가 제한된 환경에서는 시스템에 최소 1GB의 스왑을 구성하는 것이 좋습니다. 이에 대한 여러 개의 가이드가 있습니다:
구성한 후에는 스왑이 올바르게 활성화되었는지 확인해야 합니다:
free -h
total used free shared buff/cache available
Mem: 1.9Gi 115Mi 1.4Gi 0.0Ki 475Mi 1.6Gi
Swap: 1.0Gi 0B 1.0Gi
또한 시스템에서 스왑 공간을 얼마나 자주 사용할지를 구성할 수 있습니다. /proc/sys/vm/swappiness를 조정하여 스와핑을 구성할 수 있습니다. 스와피니스는 0에서 100 사이의 값을 가지며 기본 값은 60입니다. 낮은 값은 Linux의 무작위 익명 메모리 페이지를 해제하고 이를 스왑에 기록하는 선호도를 감소시키지만 파일 지원 페이지에 대해 동일한 작업을 수행하는 선호도를 증가시킵니다:
-
현재 세션에서 구성:
sudo sysctl vm.swappiness=10 -
영구적으로 구성하려면
/etc/sysctl.conf를 편집합니다:vm.swappiness=10
GitLab 설치
메모리 제한 환경에서는 GitLab 배포판을 신중하게 선택해야 합니다.
GitLab Enterprise Edition (EE)는 GitLab Community Edition (CE)보다 훨씬 많은 기능을 제공하지만, 모든 이러한 추가 기능은 계산 및 메모리 요구 사항을 증가시킵니다.
메모리 소비가 주요 고려 사항인 경우에는 GitLab CE를 설치하세요. 나중에 항상 GitLab EE로 업그레이드할 수 있습니다.
Puma 최적화
경고: 이 기능은 실험적인 알파 기능이며 예고없이 변경될 수 있습니다. 이 기능은 생산 환경에서 사용할 준비가 되어 있지 않습니다. 이 기능을 사용하려면 먼저 비생산 데이터로 테스트하는 것이 좋습니다. 추가 정보는 알려진 이슈를 확인하세요.
기본적으로 GitLab은 많은 동시 연결을 처리하도록 설계된 구성으로 실행됩니다.
고처리량이 필요없는 소규모 설치의 경우, Puma Clustered mode을 비활성화하는 것을 고려해보세요. 이로 인해 단일 Puma 프로세스만 애플리케이션을 제공하게 됩니다.
/etc/gitlab/gitlab.rb에서:
puma['worker_processes'] = 0
이렇게 Puma를 구성함으로써 메모리 사용량이 100-400MB 감소하는 것을 관찰했습니다.
Sidekiq 최적화
Sidekiq는 백그라운드 처리 데몬입니다. GitLab과 기본적으로 구성될 때
20의 동시성 모드로 실행됩니다. 이는 한 번에 할당할 수있는 메모리에 영향을 미칩니다. 이를 5 또는 10 (권장)과 같이 크게 작은 값으로 구성하는 것이 좋습니다.
/etc/gitlab/gitlab.rb에서:
sidekiq['concurrency'] = 10
Gitaly 최적화
Gitaly는 Git 기반 저장소에 효율적인 액세스를 허용하는 저장소 서비스입니다. Gitaly에서 강제 적용된 최대 동시성 및 메모리 한도를 구성하는 것이 좋습니다.
/etc/gitlab/gitlab.rb에서:
gitaly['configuration'] = {
concurrency: [
{
'rpc' => "/gitaly.SmartHTTPService/PostReceivePack",
'max_per_repo' => 3,
}, {
'rpc' => "/gitaly.SSHService/SSHUploadPack",
'max_per_repo' => 3,
},
],
cgroups: {
repositories: {
count: 2,
},
mountpoint: '/sys/fs/cgroup',
hierarchy_root: 'gitaly',
memory_bytes: 500000,
cpu_shares: 512,
},
}
gitaly['env'] = {
'GITALY_COMMAND_SPAWN_MAX_PARALLEL' => '2'
}
모니터링 비활성화
GitLab은 추가 구성 없이 완전한 DevOps 솔루션을 제공하기 위해 기본적으로 모든 서비스를 활성화합니다. 모니터링과 같은 기본 서비스 중 일부는 GitLab의 기능을 제공하는 데 필수적이지 않으며 메모리를 절약하기 위해 비활성화할 수 있습니다.
/etc/gitlab/gitlab.rb에서:
prometheus_monitoring['enable'] = false
이렇게 GitLab을 구성함으로써 메모리 사용량이 200MB 감소하는 것을 관찰했습니다.
GitLab 메모리 처리 방법 구성
GitLab은 많은 컴포넌트(Ruby 및 Go로 작성됨)로 구성되어 있으며, 그 중에서 GitLab Rails가 가장 크며 가장 많은 메모리를 사용합니다.
GitLab Rails은 메모리 할당기로써 jemalloc을 사용합니다. jemalloc은 성능을 향상시키기 위해 더 큰 청크로 메모리를 미리 할당하며 더 오랫동안 유지합니다. 성능 일부를 희생하여 GitLab을 구성하여 보다 오랜 기간 메모리를 보유하는 대신 더 이상 필요하지 않은 메모리를 즉시 해제하도록 설정할 수 있습니다.
/etc/gitlab/gitlab.rb에서:
gitlab_rails['env'] = {
'MALLOC_CONF' => 'dirty_decay_ms:1000,muzzy_decay_ms:1000'
}
gitaly['env'] = {
'MALLOC_CONF' => 'dirty_decay_ms:1000,muzzy_decay_ms:1000'
}
이렇게 애플리케이션이 실행되는 동안 메모리 사용량이 훨씬 안정적인 것을 관찰했습니다.
추가 내부 모니터링 비활성화
GitLab은 자체의 다양한 측면을 측정하기 위해 내부 데이터 구조를 사용합니다. 모니터링이 비활성화되면 이러한 기능은 더 이상 필요하지 않습니다.
이러한 기능을 비활성화하려면 GitLab의 관리자 영역으로 이동하여 Prometheus Metrics 기능을 비활성화해야 합니다:
- 왼쪽 사이드바에서 맨 아래에서 관리자 영역을 선택합니다.
- 설정 > 메트릭 및 프로파일링을 선택합니다.
- Metrics - Prometheus를 확장합니다.
- Prometheus Metrics 사용을 비활성화합니다.
- 변경 사항 저장을 선택합니다.
변경 사항이 포함된 구성
-
지금까지 설명한 모든 내용을 적용하면
/etc/gitlab/gitlab.rb파일에 다음 구성이 포함되어 있어야 합니다:puma['worker_processes'] = 0 sidekiq['concurrency'] = 10 prometheus_monitoring['enable'] = false gitlab_rails['env'] = { 'MALLOC_CONF' => 'dirty_decay_ms:1000,muzzy_decay_ms:1000' } gitaly['configuration'] = { concurrency: [ { 'rpc' => "/gitaly.SmartHTTPService/PostReceivePack", 'max_per_repo' => 3, }, { 'rpc' => "/gitaly.SSHService/SSHUploadPack", 'max_per_repo' => 3, }, ], cgroups: { repositories: { count: 2, }, mountpoint: '/sys/fs/cgroup', hierarchy_root: 'gitaly', memory_bytes: 500000, cpu_shares: 512, }, } gitaly['env'] = { 'MALLOC_CONF' => 'dirty_decay_ms:1000,muzzy_decay_ms:1000', 'GITALY_COMMAND_SPAWN_MAX_PARALLEL' => '2' } -
이러한 변경 사항을 모두 적용한 후 GitLab을 새 설정을 사용하도록 다시 구성하세요:
sudo gitlab-ctl reconfigure이 작업은 GitLab이 이전까지 메모리 절약 설정으로 작동하지 않았기 때문에 시간이 걸릴 수 있습니다.
성능 결과
위의 구성을 적용한 후 다음과 같은 메모리 사용량을 기대할 수 있습니다:
total used free shared buff/cache available
Mem: 1.9Gi 1.7Gi 151Mi 31Mi 132Mi 102Mi
Swap: 1.0Gi 153Mi 870Mi
도움말