구성요소(Components) 요구사항
GitLab 구성요소가 최적의 성능으로 작동하기 위해서는 각 구성요소별로 버전 및 설정 권장사항을 따르는 것이 좋습니다.
데이터베이스
PostgreSQL은 Omnibus GitLab 패키지와 함께 번들로 제공되는 유일하게 지원되는 데이터베이스입니다. 외부 PostgreSQL 데이터베이스를 사용할 수도 있습니다. MySQL에 대한 지원은 GitLab 12.1에서 제거되었습니다. MySQL/MariaDB와 함께 GitLab을 사용하는 기존 사용자는 업그레이드하기 전에 PostgreSQL로 마이그레이션하는 것이 좋습니다.
PostgreSQL 요구사항
정확한 요구사항은 사용자 수에 따라 다르지만, PostgreSQL을 실행하는 서버에는 최소 5~10GB의 스토리지를 사용할 수 있어야 합니다.
개발 및 테스트에 사용된 최소 PostgreSQL 버전(다음 표에 명시된 대로)을 사용하는 것이 좋습니다.
GitLab 버전 | 최소 PostgreSQL 버전 |
---|---|
13.0 | 11 |
14.0 | 12 |
또한 다음 익스텐션(Extension)이 GitLab 데이터베이스에 모두 로드되었는지 확인해야 합니다. 이 요구사항 및 트러블슈팅에 대해 자세히 알아보세요.
익스텐션 | 최소 GitLab 버전 |
---|---|
pg_trgm | 8.6 |
btree_gist | 13.1 |
plpgsql | 11.7 |
PostgreSQL 9.6 및 10에 대한 지원이 GitLab 13.0에서 제거되어 GitLab은 파티셔닝(Partitioning)과 같은 PostgreSQL 11 개선사항의 이점을 누릴 수 있습니다. PostgreSQL 12로의 전환 일정은 관련 에픽을 참조하세요.
GitLab Geo에 대한 추가 요구 사항
GitLab Geo를 사용하는 경우 Omnibus GitLab 관리형 인스턴스를 실행하는 것이 좋습니다. 이를 기반으로 적극적으로 개발 및 테스트하기 때문입니다. GitLab 팀은 대부분의 외부(Omnibus GitLab에서 관리하지 않음) 데이터베이스(예: AWS Relational Database Service(RDS))와 호환되도록 노력하고 있지만 호환성을 보장할 수 없습니다.
Gitaly 클러스터 데이터베이스 요구 사항
자세한 내용은 Gitaly Cluster 문서를 참조하세요.
GitLab 데이터베이스의 독점적인 사 용
GitLab, Geo, Gitaly Cluster 또는 기타 구성요소를 위해 생성되거나 사용되는 데이터베이스는 GitLab 전용이어야 합니다. GitLab 설명서의 절차를 따르거나 GitLab 지원팀 또는 GitLab 엔지니어의 지시를 따르는 경우를 제외하고 데이터베이스, 스키마, 사용자 또는 기타 속성을 직접 변경하지 마십시오.
- 주요 GitLab 애플리케이션은 현재 세 가지 스키마를 사용합니다.
- 기본
public
스키마 gitlab_partitions_static
(자동 생성)gitlab_partitions_dynamic
(자동 생성) 다른 스키마는 수동으로 생성하면 안 됩니다.
- 기본
- GitLab은 Rails 데이터베이스 마이그레이션의 일부로 새 스키마를 생성할 수 있습니다. 이것은 GitLab 업그레이드를 수행할 때 발생합니다. 이 작업을 수행하려면 GitLab 데이터베이스 계정에 액세스 권한이 필요합니다.
- GitLab은 업그레이드 프로세스 중에 테이블을 생성하고 수정하며, 파티션 된 테이블을 관리하기 위한 일반 작업의 일부로도 사용됩니다.
- GitLab 스키마를 수정하면 안 됩니다.(예: 트리거 추가 또는 테이블 수정) 데이터베이스 마이그레이션은 GitLab 코드베이스의 스키마 정의에 대해 테스트됩니다. 스키마를 수정하면 GitLab 버전 업그레이드가 실패할 수 있습니다.
Puma 설정
Puma에 대한 권장 설정 은 실행 중인 인프라에 따라 결정됩니다. GitLab Linux 패키지는 기본적으로 권장되는 Puma 설정을 사용합니다. 설치 방법에 관계없이 Puma 설정을 조정할 수 있습니다.
- GitLab Linux 패키지를 사용하는 경우 Puma 설정 변경에 대한 지침은 Puma 설정을 참조하세요.
- GitLab Helm chart를 사용하는 경우 Webservice chart를 참조하세요.
Puma workers
권장 워커 수는 다음 중 가장 높은 것으로 계산됩니다.
2
- CPU 및 메모리 리소스 가용성의 조합(Linux 패키지에 대해 자동으로 구성되는 방법 참조)
다음 시나리오를 예로 들어 보겠습니다.
- 2Cores/8GB 메모리가 있는 노드는 2개의 Puma 워커로 구성되어야 합니다.
다음과 같이 계산됩니다.
The highest number from
2
And
[
the lowest number from
- number of cores: 2
- memory limit: (8 - 1.5) = 6
]
따라서 2와 2에서 가장 높은 값은 2입니다.
- 4Cores/4GB 메모리가 있는 노드는 2개의 Puma 워커로 구성되어야 합니다.
The highest number from
2
And
[
the lowest number from
- number of cores: 4
- memory limit: (4 - 1.5) = 2.5
]
따라서 2와 2에서 가장 높은 값은 2입니다.
- 4Cores/8GB 메모리가 있는 노드는 4개의 Puma 워커로 구성되어야 합니다.
The highest number from
2
And
[
the lowest number from
- number of cores: 4
- memory limit: (8 - 1.5) = 6.5
]
따라서 2와 4에서 가장 높은 값은 4입니다.
충분한 CPU 및 메모리 용량을 사용할 수 있으면 Puma 워커의 수를 늘릴 수 있습니다. 일반적으로 Puma 워커의 수가 많을수록 애플리케이션의 응답 시간을 줄이고 병렬 요청을 처리하는 능력을 높이는데 도움이 됩니다. 인프라에 대한 최적의 설정을 확인하려면 테스트를 수행해야 합니다.