인스턴스에서 GitHub Enterprise Server Git 트래픽 분석

주지사 정보

Governor는 인스턴스에서 Git 작업에 대한 기본 제공 모니터입니다. ghe-governor 이 명령을 사용하여 로드를 만드는 리포지토리, 사용자, IP 주소 및 Git 작업을 확인합니다.

CPU, 메모리 또는 디스크 사용량이 증가하고 Git 트래픽이 원인인지 확인해야 하는 경우 이 데이터를 사용합니다. 명령 구문 및 하위 명령은 명령줄 유틸리티을 참조하세요.

관리자가 Git 작업만 기록합니다. API 또는 웹 트래픽은 포함되지 않습니다. 현재 실행 중인 작업을 검사하려면 명령줄 유틸리티의 ghe-btop 유틸리티를 참조하세요.

관리자 데이터 파일 정보

관리자가 해당 데이터를 아래의 파일에 저장합니다 /data/user/governor/. 각 파일은 1시간의 데이터를 보유하며 2주 동안 보존됩니다. 파일 이름에는 각 파일이 다루는 기간을 나타내는 Unix 타임스탬프가 포함됩니다.

참고

GitHub Enterprise Server 3.13 및 이전 버전에서는 관리자 데이터 파일이 아래에 /data/user/gitmon/ 있으며 명명 패턴을 gitmon.<timestamp>.db사용합니다.

현재 디스크에 보관된 데이터 범위를 확인하려면 초기 및 최신 파일 이름의 타임스탬프를 사람이 읽을 수 있는 날짜로 변환합니다.

for epoch in $(sudo ls /data/user/governor/ 2>/dev/null | grep '^governor\.' | sort | sed -n '1p;$p' | cut -f2 -d.); do echo "${epoch} = $(date -d @${epoch})"; done

출력은 가장 이른 데이터 파일과 최신 데이터 파일의 시작 시간을 보여줍니다.

1551186000 = Tue Feb 26 13:00:00 UTC 2019
1552392000 = Tue Mar 12 12:00:00 UTC 2019

시작하기 전에

관리자 쿼리를 실행하기 전에 다음 정보를 수집합니다.

어플라이언스 SSH 액세스 를 실행 ghe-governor하려면 관리 셸에 대한 액세스 권한이 필요합니다. 관리 셸(SSH)에 액세스을(를) 참조하세요.
쿼리할 노드입니다. 독립 실행형 또는 고가용성 배포의 경우 주 노드에서 시작합니다. 클러스터의 경우 모든 Git 트래픽을 포함하는 단일 노드가 없으므로 각 git-server 노드에서 쿼리를 실행합니다.
영향 창입니다. 쿼리 범위를 지정할 수 있도록 보고된 성능 저하의 시작 및 종료 시간을 기록해 둡니다 -t``-u.
사용자가 특정 리포지토리 또는 조직에 문제를 보고한 경우 리포지토리 또는 조직 이름입니다.

Git이 로드에 기여하는지 확인

광범위한 요약으로 시작한 다음 특정 리포지토리 또는 프로그램에 특성 로드를 시작합니다.

인스턴스의 모든 최근 Git 활동을 요약합니다.
```
ghe-governor health
```
평균 응답 시간이 가장 느린 리포지토리를 찾습니다.
```
ghe-governor aggregate repo avg_rt
```
가장 긴 단일 작업을 사용하여 리포지토리를 찾습니다.
```
ghe-governor aggregate repo max_rt
```
가장 느린 개별 작업(그룹화되지 않음)을 찾습니다.
```
ghe-governor top rt -n 50
```
CPU 시간이 가장 많이 소요되는 리포지토리를 찾습니다.
```
ghe-governor aggregate repo cpu
```
눈에 띄는 리포지토리의 경우 CPU 사용을 담당하는 Git 하위 프로그래밍을 찾습니다.
```
ghe-governor aggregate program cpu -r OWNER/REPOSITORY
```
CPU 시간이 가장 많이 사용된 리포지 pack-objects 토리를 찾습니다. 이 pack-objects 프로그램은 클론 및 페치 중에 클라이언트에 전송된 데이터를 어셈블합니다. 개수가 많을수록 어플라이언스에 상당한 CPU 및 메모리 압력이 발생합니다.
```
ghe-governor aggregate repo cpu -P pack-objects
```
가장 많은 CPU 시간을 사용한 개별 작업을 찾습니다(그룹화되지 않음).
```
ghe-governor top cpu -n 50
```
특정 시간 간격 동안 가장 많은 디스크 쓰기를 구동하는 리포지토리를 찾습니다.
```
ghe-governor aggregate repo disk_write_kb -t START-TIME -u END-TIME
```
동시에 실행되는 많은 Git 작업을 나타내는 높은 동시성을 확인합니다.
```
ghe-governor aggregate repo max_parallelism
```

결과가 특정 리포지토리 또는 프로그램을 가리키는 경우 아래 관련 섹션을 계속 진행합니다.

상위 복제본 식별 및 트래픽 가져오기

이 upload-pack 프로그램은 클론 및 페치 중에 클라이언트에 제공된 데이터를 처리합니다. 이러한 쿼리를 사용하여 복제 및 페치 작업을 가장 많이 구동하는 리포지토리, 사용자 및 IP 주소를 찾습니다.

리포지토리별 복제 및 페치 작업 수:

ghe-governor aggregate repo count -P upload-pack

클론을 실행하는 사용자를 식별하고 작업을 페치하고 계산합니다.
```
ghe-governor aggregate user_id count -P upload-pack
```
가장 많은 클론 및 페치 요청을 생성하는 IP 주소를 식별합니다. 개수가 많은 작은 IP 주소 집합은 종종 CI 실행기 플릿을 나타냅니다.
```
ghe-governor aggregate ip count -P upload-pack
```
리포지토리당 제공되는 데이터의 총 볼륨을 측정합니다.
```
ghe-governor aggregate repo uploaded_kb -P upload-pack
```
사용자당 업로드된 데이터의 평균 볼륨을 측정합니다.
```
ghe-governor aggregate user_id avg_uploaded -P upload-pack
```
최대 복제본을 찾고 리포지토리당 동시성을 가져옵니다. 이 열에는 MAXPL 각 리포지토리에 대해 기록된 가장 많은 동시 작업이 표시됩니다. 적은 수의 리포지토리에 대한 높은 값은 천둥 무리가 있음을 시사합니다.
```
ghe-governor aggregate repo max_parallelism -P upload-pack
```
가장 큰 개별 클론 또는 페치 작업(그룹화되지 않음)을 찾습니다.
```
ghe-governor top uploaded -P upload-pack -n 50
```

푸시가 많은 트래픽 식별

receive-pack 및 spokes-receive-pack 프로그램은 푸시 중에 클라이언트에서 받은 데이터를 처리합니다. 이러한 쿼리를 사용하여 가장 많은 푸시 작업을 생성하는 리포지토리, 사용자 및 IP 주소를 찾습니다.

리포지토리별 푸시 작업 수:

ghe-governor aggregate repo count -P receive-pack -P spokes-receive-pack

조직에 푸시하는 사용자를 식별하고 푸시 작업 수를 계산합니다.

ghe-governor aggregate user_id count -o ORGANIZATION -P receive-pack -P spokes-receive-pack

리포지토리당 수신된 데이터의 총 볼륨을 측정합니다.

ghe-governor aggregate repo received_kb -P receive-pack -P spokes-receive-pack

가장 많은 푸시 데이터를 보내는 IP 주소를 식별합니다.

ghe-governor aggregate ip received_kb -P receive-pack -P spokes-receive-pack

그룹화되지 않은 가장 큰 개별 푸시 작업을 찾습니다.

ghe-governor top received -P receive-pack -P spokes-receive-pack -n 50

분석 범위 좁히기

다음 옵션 ghe-governor top 의 조합을 명령이나 ghe-governor aggregate 명령에 추가하여 특정 기간, 리포지토리, 소유자 또는 프로그램에 쿼리를 집중할 수 있습니다.

시간 필터

Option	Description
`-t <timespec>`	지정된 시작 시간 이후의 작업만 고려합니다. 기본값은 48시간 전입니다.
`-u <timespec>`	지정된 종료 시간까지의 작업만 고려합니다. 기본값은 현재 시간입니다.

다음과 같은 형식이 허용 <timespec>됩니다.

포맷	Example	Meaning
Unix 타임스탬프	`-t 1371614483`	1970년 1월 1일 이후의 초
Java 타임스탬프	`-t 1371614483637`	1970년 1월 1일 이후 밀리초
상대 일수	`-t 1d`	마지막 날
상대 시간	`-t 2h`	지난 2시간
상대 시간(분)	`-t 20m`	마지막 20분

범위 필터

Option	Description
`-r <owner>/<repository>`	지정된 소유자 및 리포지토리와 일치하는 작업만 고려합니다. 여러 리포지토리와 일치하도록 이 옵션을 여러 번 지정합니다.
`-o <owner>`	사용자 또는 조직과 같이 지정된 소유자와 일치하는 작업만 고려합니다. 여러 소유자와 일치하도록 이 옵션을 여러 번 지정합니다.
`-P <program>`	지정된 Git 하위 프로그래밍(예: `upload-pack`, receive-pack``rev-list또는 `pack-objects`)을 실행한 작업만 고려합니다. 여러 프로그램과 일치하도록 이 옵션을 여러 번 지정합니다.
`-I <address>`	특정 IP 주소의 작업만 고려합니다. 여러 주소와 일치하도록 이 옵션을 여러 번 지정합니다.

출력 옵션

Option	Description
`-j`	출력 형식을 ASCII 테이블 대신 JSON으로 설정합니다.
`-n <N>`	출력을 N 레코드로 제한합니다. 기본값은 집계 쿼리의 경우 20개, 상위 쿼리의 경우 200개입니다.
`--count-only`	열과 `COUNT` 열만 `KEY` 표시합니다. 집계 쿼리에만 적용됩니다.

결과 열 해석

다음 약어는 결과 테이블에 표시됩니다 ghe-governor .

Column	Meaning
`AVG RT`	Git 호출에 걸린 평균 시간(초)입니다.
`MAX RT`	호스트당 가장 오래 실행되는 호출의 실행 시간(초)입니다.
`MAXPL` / `AVGPL`	최대 및 평균 병렬 처리: 한 번에 처리된 Git 호출 수
`CPU/SEC`	벽시계 시간의 초당 Git에서 사용하는 CPU 시간(초)입니다. CPU 코어 수를 나누고 100을 곱하여 Git별 CPU 비율을 가져옵니다. 이 값은 CPU 코어 수를 초과할 수 없습니다.
`UPL`	페치 및 복제 중과 같이 서버가 클라이언트에 업로드한 데이터
`RECV`	서버가 클라이언트로부터 받은 데이터(예: 푸시 중)

, WRITE및 UPL``RECV 열은 READ기가바이트(GB)로 보고되며, 해당 속도는 초당 메가바이트(MB/s)로 보고됩니다.

일반적인 패턴 해석

다음 표에서는 일반적인 Governor 출력 패턴을 해당 원인에 매핑합니다.

Pattern	가능한 원인
작은 IP 주소 집합에서 개 `upload-pack` 수 높음	CI Runner 플릿은 로컬 체크 아웃을 다시 사용하는 대신 하나 이상의 리포지토리를 반복적으로 복제합니다.
적은 수의 리포지토리에 대해 높 `max_parallelism` 음	천둥 무리 : 예약 된 작업이 동시에 시작되기 때문에 많은 주자가 동시에 동시 클론을 트리거합니다.
사용자당 높음과 결합된 리포지토리당 큰 uploaded_kb``avg_uploaded 리포지토리	반복된 전체 클론; 클라이언트가 로컬 체크 아웃을 다시 사용하지 않거나 단순 또는 부분 클론을 사용하지 않습니다.
리포지토리 또는 조직의 경우 높음 `received_kb`	푸시 집약적 워크로드; 에는 큰 이진 파일 또는 monorepo에 대한 빈번한 커밋이 포함될 수 있습니다.
보통 작업 수가 있는 높은 `pack-objects` CPU	비용이 많이 드는 개체 압축; 리포지토리는 유지 관리 실행 또는 클라이언트 쪽에서 부분 클론을 사용할 때 도움이 될 수 있습니다. `--filter`
높 `avg_rt` 음 또는 `max_rt` 리포지토리의 경우	느린 작업; 대용량 `pack-objects` 실행, 높은 동시성 또는 다른 워크로드의 리소스 경합으로 인해 발생하는 경우가 많습니다.

Git 부하 감소에 권장되는 작업

관리자 데이터에 리포지토리, 사용자 또는 실행기 플릿이 과도한 부하를 생성하는 것으로 표시되면 다음 작업을 수행하면 영향을 줄일 수 있습니다.

로컬 체크 아웃을 다시 사용합니다. 새 클론을 git fetch 자동화된 워크플로로 바꿉니다. 이렇게 하면 각 실행에서 전체 개체 그래프가 전송되는 것을 방지할 수 있습니다.
단순 클론을 사용합니다. 전체 커밋 기록이 필요하지 않은 워크플로의 경우 복제 명령(예: git clone --depth 1)에 전달 --depth 합니다. 이렇게 하면 전송된 데이터와 수행해야 하는 작업이 pack-objects 모두 줄어듭니다.
부분 클론을 사용합니다. 큰 이진 개체가 있는 리포지토리 또는 지정된 워크플로에 필요하지 않은 파일이 많은 리포지토리의 경우 워크플로 --filter 에 필요한 개체만 요청합니다. 예를 들면 다음과 같습니다 git clone --filter=blob:none.
로컬 미러 또는 캐싱 프록시를 추가합니다. 동일한 리포지토리를 반복적으로 복제하는 대규모 실행기 플릿의 경우 풀스루 프록시 또는 로컬 미러는 페치 트래픽을 흡수하고 인스턴스의 부하를 줄일 수 있습니다.
예약된 작업을 중지합니다. 일정에 따라 트리거되는 CI/CD 워크플로를 오프셋하여 모든 실행기가 동시에 시작되지 않도록 하여 동시 클론 버스트의 크기를 줄입니다.
워크플로 병렬 처리를 줄입니다. 여러 리포지토리를 병렬로 복제하는 워크플로를 다시 구성하여 동시성을 제한하고 시간에 따라 부하를 분산할 수 있습니다.

지원에 문의 GitHub 하는 경우

다음 중 어느 것이 적용되는 경우 지원 번들에 문의 GitHub Enterprise 지원 하여 포함합니다.

복제 압력을 줄이거나 예약된 작업을 엄청나게 줄인 후에도 성능이 저하된 상태로 유지됩니다.
인스턴스는 클라이언트 워크로드에서 설명하지 않는 광범위한 Git 오류 또는 연결 오류를 제공합니다.
관리자가 인스턴스가 용량에 가깝거나 용량에 근접했음을 나타내는 영구 max_parallelism 값을 표시하며 워크로드 변경만으로는 문제를 해결할 가능성이 낮습니다.
주지사 출력에 명확한 패턴이 표시되지만 해석 방법이나 수행할 조치가 불확실합니다.

지원 번들을 생성하는 방법에 대한 자세한 내용은 GitHub 지원에 데이터 제공을 참조하세요.

추가 읽기

시스템 리소스 모니터링에 대한 자세한 내용은 모니터 대시보드 정보을 참조하세요.

인스턴스에서 GitHub Enterprise Server Git 트래픽 분석

이 기사에서