- 제한된 환경을 위한 최소 요구 사항
- 시스템 성능 확인
- 스왑 구성
- GitLab 설치
- Puma 최적화
- Sidekiq 최적화
- Gitaly 최적화
- 모니터링 비활성화
- GitLab 메모리 처리 방식 구성
- 추가 내부 모니터링 비활성화
- 모든 변경 사항 구성
- 성능 결과
메모리 제한 환경에서 GitLab 실행하기
모든 기능이 활성화된 상태에서 GitLab을 실행하는 데 상당한 양의 메모리가 필요합니다. 그러나 개인용 또는 매우 작은 팀용으로 GitLab을 실행하거나 모든 기능이 필요하지 않은 클라우드 제공 업체의 작은 인스턴스를 사용하여 비용을 절감하거나 Raspberry PI와 같은 자원 제한 장치를 사용하는 경우와 같이 기능을 모두 사용하지 않아도 되는 사용 사례가 있습니다.
GitLab이 최소 요구 사항(여기 참조)이나 참조 아키텍처(여기 참조)에서 설명된 것보다 훨씬 낮은 규격에서도 편안하게 실행될 수 있도록 몇 가지 조정을 통해 GitLab이 실행될 수 있습니다.
다음 섹션에는 최소 요구 사항을 충족시키지 못하는 환경에서 GitLab을 실행할 수 있도록 하는 조언이 포함되어 있습니다. 대부분의 GitLab 컴포넌트는 이러한 설정이 적용된 상태에서 작동해야 하지만 제품 기능과 성능의 예상치 못한 저하가 발생할 수 있습니다. 개발자 최대 5명이며 개별 Git 프로젝트의 크기가 100MB를 넘지 않는 경우에 GitLab을 실행할 수 있어야 합니다.
제한된 환경을 위한 최소 요구 사항
GitLab이 실행될 수 있는 최소 규격은 다음과 같습니다.
- 리눅스 기반 시스템 (이상적으로 데비안 기반 또는 레드햇 기반)
- ARM7/ARM64의 4개 CPU 코어 또는 AMD64 아키텍처의 1개 CPU 코어
- 최소 2GB RAM + 1GB SWAP, 최적 2.5GB RAM + 1GB SWAP
- 20GB 사용 가능한 저장 공간
- 다음 중 무작위 I/O 성능이 좋은 리포지터리 (선호 순서대로):
위 디렉터리 중에서 CPU의 단일 코어 성능과 리포지터리의 무작위 I/O 성능이 가장 큰 영향을 미칩니다. 특히 리포지터리는 제한된 환경에서 사용자가 기대하는 대로 일부 메모리 스와핑이 발생할 것으로 예상되므로 사용된 디스크에 더 많은 압력이 가해집니다. 작은 플랫폼의 제한된 성능의 일반적인 문제는 매우 느린 디스크 리포지터리로 인해 시스템 전체적인 병목 현상이 발생하는 것입니다.
이러한 최소 설정으로 시스템은 정규 작동 중에 스왑을 사용해야 합니다. 모든 컴포넌트가 동시에 사용되는 것은 아니기 때문에 수용 가능한 성능을 제공해야 합니다.
시스템 성능 확인
리눅스 기반 시스템의 성능을 확인할 수 있는 여러 도구가 있습니다. 시스템 성능을 검사하는 데 도움을 줄 수 있는 프로젝트 중 하나는 sbc-bench입니다. 이는 내장 시스템에서 GitLab을 실행할 때 특히 중요한 시스템 테스트의 모든 경고 및 서로 다른 동작의 성능에 미치는 영향에 대해 설명합니다. 이를 통해 제한된 환경에서 시스템의 성능이 GitLab을 실행하기에 충분한지를 검증할 수 있습니다.
다음 시스템은 작은 GitLab 설치에 적합한 충분한 성능을 제공합니다.
스왑 구성
GitLab을 설치하기 전에 스왑을 구성해야 합니다. 스왑은 물리적 RAM이 가득 차면 사용되는 디스크의 전용 공간입니다. 리눅스 시스템이 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입니다. 낮은 값은 리눅스의 익명 메모리 페이지를 해제하는 것에 대한 선호도를 낮추지만 파일 지원 메모리 페이지를 해제하는 것에 대한 선호도를 높입니다.
-
현재 세션에서 구성:
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 클러스터 모드를 비활성화하는 것을 고려하십시오. 결과적으로 단일 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은 많은 컴포넌트(루비 및 고로 작성됨)로 이루어져 있는데, 그 중에서 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의 관리 영역으로 이동해야 합니다:
- 왼쪽 사이드바에서 가장 하단에 관리 영역을 선택합니다.
- 설정 > 메트릭 및 프로파일링을 선택합니다.
- 메트릭 - 프로메테우스를 확장합니다.
- 프로메테우스 메트릭 활성화를 비활성화합니다.
- 변경 사항 저장을 선택합니다.
모든 변경 사항 구성
-
지금까지 설명한 모든 것을 적용하면
/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
도움말