리소스 사용
리소스 요청
우리의 모든 컨테이너에는 미리 정의된 리소스 요청 값이 포함되어 있습니다. 기본적으로 리소스 제한을 설정하지 않았습니다. 노드에 여유 메모리 용량이 없는 경우, 메모리 제한을 적용하는 한 가지 옵션은 더 많은 메모리(또는 노드)를 추가하는 것입니다. (Linux 커널의 메모리 부족 관리자가 중요한 Kube 프로세스를 종료할 수 있음을 고려해야 합니다.)
우리의 기본 요청 값들을 설정하기 위해, 우리는 애플리케이션을 실행하고, 각 서비스에 대한 여러 수준의 부하를 생성하는 방법을 고안합니다. 우리는 서비스를 모니터링하고, 최상의 기본 값을 결정합니다.
우리는 다음을 메트릭할 것입니다:
-
유휴 부하 - 기본값이 이 값보다 작지 않아야 하지만, 유휴 프로세스는 유용하지 않으므로 일반적으로 이 값을 기준으로 기본값을 설정하지 않을 것입니다.
-
최소 부하 - 가장 기본적이고 유용한 작업을 수행하는 데 필요한 값들입니다. 일반적으로 CPU에 대해서는 이 값이 기본값으로 사용되겠지만, 메모리 요청은 커널이 프로세스를 제거할 위험이 있으므로 이 값을 메모리의 기본값으로 사용할 것을 피할 것입니다.
-
평균 부하 - 평균이라고 여겨지는 것은 설치에 따라 매우 의존적입니다. 우리의 기본값으로는 몇 가지 메트릭을 시도하여 합리적인 부하로 간주되는 몇 가지 메트릭을 사용합니다. (사용한 부하를 나열할 것입니다.) 서비스에 pod 오토스케일러가 있는 경우, 일반적으로 우리는 이 값을 기반으로 스케일링 대상 값을 설정하려고 할 것입니다. 그리고 또한 기본 메모리 요청입니다.
-
스트레스 작업 - 서비스가 수행해야 할 가장 스트레스 받는 작업의 사용을 메트릭합니다. (부하에서는 반드시 발생하지 않음) 리소스 제한을 적용할 때에는 이보다 높거나 평균 부하 값 이상의 제한을 설정하려고 노력할 것입니다.
-
고부하 - 서비스에 대한 스트레스 테스트를 수행하고, 그런 다음 이를 수행하는 데 필요한 리소스 사용을 메트릭합니다. 현재 우리는 기본값으로 이러한 값들을 사용하지 않지만, 사용자는 일반적으로 평균 부하/스트레스 작업과 이 값 사이의 어딘가에 리소스 제한을 설정하려고 할 것입니다.
GitLab Shell
부하는 일부 동시성을 가지려는 목적으로 nohup git clone <프로젝트> <임의의 경로 이름>
을 호출하는 bash 루프를 사용하여 테스트되었습니다. 향후 테스트에서는 다른 서비스에 대해 수행한 테스트 유형과 보다 일치하도록 지속적인 동시 부하를 포함하려고 할 것입니다.
-
유휴 값
- 0 작업, 2 pod
- CPU: 0
- 메모리:
5M
- 0 작업, 2 pod
-
최소 부하
- 1 작업 (빈 클론 1개), 2 pod
- CPU: 0
- 메모리:
5M
- 1 작업 (빈 클론 1개), 2 pod
-
평균 부하
- 5개 병렬 클론, 2 pod
- CPU:
100m
- 메모리:
5M
- CPU:
- 20개 병렬 클론, 2 pod
- CPU:
80m
- 메모리:
6M
- CPU:
- 5개 병렬 클론, 2 pod
-
스트레스 작업
- Linux 커널을 SSH로 클론 (17MB/s)
- CPU:
280m
- 메모리:
17M
- CPU:
- Linux 커널을 SSH로 푸시 (2MB/s)
- CPU:
140m
- 메모리:
13M
- 업로드 연결 속도는 테스트 중에 아마도 영향을 미쳤을 것입니다
- CPU:
- Linux 커널을 SSH로 클론 (17MB/s)
-
고부하
- 100개 병렬 클론, 4 pod
- CPU:
110m
- 메모리:
7M
- CPU:
- 100개 병렬 클론, 4 pod
-
기본 요청
- CPU: 0 (최소 부하에서)
- 메모리:
6M
(평균 부하에서) - 대상 CPU 평균:
100m
(평균 부하 값에서)
-
권장 제한
- CPU: >
300m
(스트레스 작업보다 큼) - 메모리: >
20M
(스트레스 작업보다 큼)
- CPU: >
gitlab.gitlab-shell.resources.limits.memory
를 너무 낮게 설정하면 문제 해결 문서에서 어떤 문제가 발생할 수 있는지를 확인하십시오.
웹 서비스
웹 서비스 리소스는 10k 사용자용 참조 아키텍처를 사용하여 테스트하는 중에 분석되었습니다. 자세한 내용은 웹 서비스 리소스 문서에서 찾을 수 있습니다.
Sidekiq
Sidekiq 리소스는 10k 사용자용 참조 아키텍처를 사용하여 테스트하는 중에 분석되었습니다. 자세한 내용은 Sidekiq 리소스 문서에서 찾을 수 있습니다.
KAS
사용자들의 필요성에 대해 더 많은 정보를 알기 전에, 우리는 우리의 사용자들이 다음과 같은 방식으로 KAS를 사용할 것으로 예상합니다.
-
유휴 값
- 0개의 에이전트가 연결되었고, 2 pod
- CPU:
10m
- 메모리:
55M
- CPU:
- 0개의 에이전트가 연결되었고, 2 pod
-
최소 부하:
- 1개의 에이전트가 연결되었고, 2 pod
- CPU:
10m
- 메모리:
55M
- CPU:
- 1개의 에이전트가 연결되었고, 2 pod
-
평균 부하: 클러스터에 1개의 에이전트가 연결되어 있음.
- 5개의 에이전트가 연결되었고, 2 pod
- CPU:
10m
- 메모리:
65M
- CPU:
- 5개의 에이전트가 연결되었고, 2 pod
-
스트레스 작업:
- 20개의 에이전트가 연결되었고, 2 pod
- CPU:
30m
- 메모리:
95M
- CPU:
- 20개의 에이전트가 연결되었고, 2 pod
-
고부하:
- 50개의 에이전트가 연결되었고, 2 pod
- CPU:
40m
- 메모리:
150M
- CPU:
- 50개의 에이전트가 연결되었고, 2 pod
-
추가 고부하:
- 200개의 에이전트가 연결되었고, 2 pod
- CPU:
50m
- 메모리:
315M
- CPU:
- 200개의 에이전트가 연결되었고, 2 pod
이 차트에 의해 설정된 KAS 리소스 기본값은 심지어 50개의 에이전트 시나리오를 처리하는 데 충분합니다. 우리가 추가 고부하로 간주하는 것에 도달하려면, 기본값을 조정하는 것을 고려해야 할 것입니다.
-
기본값: 각각 다음과 같은 2개의 pod
- CPU:
100m
- 메모리:
100M
- CPU:
이러한 숫자가 어떻게 계산되었는지에 대한 자세한 내용은 이슈 토론을 참조하십시오.