- 제약된 환경을 위한 최소 요구 사항
- 시스템 성능 검증하기
- 스왑 구성
- GitLab 설치
- Puma 최적화
- Sidekiq 최적화
- Gitaly 최적화
- 모니터링 비활성화
- GitLab이 메모리를 처리하는 방법 구성하기
- 애플리케이션 내 모니터링 비활성화
- 모든 변경 사항을 통한 구성
- 성능 결과
메모리 제약 환경에서 GitLab 실행하기
GitLab은 모든 기능이 활성화된 상태로 실행할 때 상당한 양의 메모리를 요구합니다.
모든 기능이 필요하지 않은 작은 설치에서 GitLab을 실행하는 경우와 같은 사용 사례가 있습니다.
예시로는 다음과 같습니다:
- 개인 사용 또는 매우 작은 팀을 위한 GitLab 실행.
- 비용 절감을 위해 클라우드 제공업체에 작은 인스턴스 사용.
- Raspberry PI와 같은 자원이 제한된 장치 사용.
일부 조정으로 GitLab은 최소 요구 사항 또는 참조 아키텍처에서 설명하는 것보다 훨씬 낮은 사양에서도 원활하게 실행될 수 있습니다.
다음 섹션에서는 GitLab이 최소 요구 사항을 충족하지 않는 환경에서 실행될 수 있도록 허용하는 조언을 포함하고 있습니다.
이 설정이 적용되면 대부분의 GitLab 구성 요소는 기능적으로 작동해야 합니다.
하지만 제품 기능과 성능 모두에서 예상치 못한 저하를 경험할 수 있습니다.
각각의 Git 프로젝트 크기가 100 MB를 초과하지 않는 최대 5명의 개발자가 GitLab을 실행할 수 있어야 합니다.
제약된 환경을 위한 최소 요구 사항
GitLab을 실행할 수 있는 최소 예상 사양은 다음과 같습니다:
- Linux 기반 시스템 (이상적으로 Debian 기반 또는 RedHat 기반)
- ARM7/ARM64의 4 CPU 코어 또는 AMD64 아키텍처의 1 CPU 코어
- 최소 2 GB의 RAM + 1 GB의 SWAP, 이상적으로 2.5 GB의 RAM + 1 GB의 SWAP
- 사용 가능한 저장소 20 GB
- 무작위 I/O 성능이 우수한 저장소, 선호 순서는 다음과 같습니다:
위 목록 중에서 CPU의 단일 코어 성능과 저장소의 무작위 I/O 성능이 가장 큰 영향을 미칩니다.
제약된 환경에서는 일정량의 메모리 스와핑이 발생할 것으로 예상되기 때문에 저장소가 특히 중요합니다.
작은 플랫폼의 제한된 성능에 대한 일반적인 문제는 매우 느린 디스크 저장소이며, 이는 시스템 전체의 병목 현상을 초래합니다.
이러한 최소 설정을 통해 시스템은 정기적인 작동 중에 SWAP을 사용할 수 있습니다.
모든 구성 요소가 동시에 사용되지 않기 때문에 수용 가능한 성능을 제공해야 합니다.
시스템 성능 검증하기
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를 조정하여 구성할 수 있습니다.
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 최적화
경고:
이것은 실험적인 Alpha 기능이며, 통지 없이 변경될 수 있습니다. 이 기능은 생산 사용에 적합하지 않습니다. 이 기능을 사용하려면, 먼저 비생산 데이터로 테스트하는 것을 권장합니다. 추가 세부정보는 알려진 문제를 참조하세요.
GitLab은 기본적으로 많은 동시 연결을 처리하도록 설계된 구성으로 실행됩니다.
높은 처리량이 필요하지 않은 소규모 설치를 위해, Puma의 클러스터 모드를 비활성화하는 것을 고려하세요. 그 결과, 단일 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은 여러 구성 요소(루비 및 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 기능을 비활성화해야 합니다:
-
왼쪽 사이드바 아래에서 Admin Area를 선택합니다.
-
Settings > Metrics and profiling을 선택합니다.
-
Metrics - Prometheus를 확장합니다.
-
Enable Prometheus Metrics를 비활성화합니다.
-
Save changes를 선택합니다.
모든 변경 사항을 통한 구성
-
지금까지 설명된 모든 내용을 적용하면,
/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
도움말