모노 레포 성능 문제 해결
모노 레포에 대한 성능 문제에 대한 제안 사항을 검토하십시오.
git clone
또는 git fetch
중 느린 작업
클론 및 페치의 속도 지연에는 몇 가지 주요 원인이 있습니다.
CPU 사용량이 높음
만약 Gitaly 노드의 CPU 사용률이 높다면, 특정 값으로 필터링하여 클론에서 사용되는 CPU 양을 확인할 수 있습니다.
특히 command.cpu_time_ms
필드는 클론 및 페치에서 사용되는 CPU 양을 나타낼 수 있습니다.
대부분의 경우, 서버 부하의 대부분은 클론 및 페치 중에 초기화되는 git-pack-objects
프로세스에서 생성됩니다. 모노 레포는 종종 매우 바쁘며 CI/CD 시스템은 많은 클론과 페치 명령을 서버로 보냅니다.
높은 CPU 사용률은 지연된 성능의 일반적인 원인입니다.
다음은 상호 배타적인 원인입니다:
원인: 너무 많은 대규모 클론
Gitaly가 처리해야 할 대규모 클론이 너무 많을 수 있습니다. Gitaly는 여러 요인으로 인해 따라잡기 어려울 수 있습니다.
- 저장소의 크기.
- 클론 및 페치의 양.
- CPU 용량 부족.
Gitaly가 많은 대규모 클론을 처리할 수 있도록 돕기 위해 일부 최적화 전략을 통해 Gitaly 서버의 부담을 줄일 수 있습니다. 예를 들어 다음과 같은 최적화 전략을 사용할 수 있습니다.
-
pack-objects-cache를 활성화하여
git-pack-objects
의 작업 부담을 줄입니다. - CI/CD 설정에서 Git 전략을
clone
에서fetch
또는none
으로 변경. - 테스트에서 필요하지 않다면 태그 검색 중지.
- 가능한 경우 얕은 클론 사용.
다른 옵션으로는 Gitaly 서버의 CPU 용량을 늘리는 것입니다.
원인: 부적절한 읽기 분배
Gitaly 클러스터에서 읽기 분배가 부적절할 수 있습니다.
주요 Gitaly 노드로 대부분의 읽기 트래픽이 이동하는지 여부를 확인하려면 읽기 분배 Prometheus 지표를 사용합니다.
만약 보조 Gitaly 노드에 트래픽이 거의 오지 않는다면, 이는 보조 노드가 영원히 동기화되지 않은 상태일 수 있습니다. 이러한 문제는 모노 레포에서 악화될 수 있습니다.
모노 레포는 종종 크고 바쁘기 때문에 두 가지 효과를 가져옵니다. 첫째, 모노 레포는 자주 푸시되고 많은 CI 작업이 실행됩니다. 브랜치를 삭제하는 것과 같은 쓰기 작업이 때로는 보조 노드에 프록시 호출이 실패할 수 있습니다. 이는 보조 Gitaly 클러스터에서 복제 작업을 트리거합니다. 그래서 보조 노드가 결국 따라잡을 수 있습니다.
복제 작업은 본질적으로 보조 노드에서 주 노드로의 git fetch
입니다. 그리고 모노 레포는 종종 매우 크기 때문에 이 작업은 오랜 시간이 소요될 수 있습니다.
만약 이전 복제 작업이 완료되기 전에 다음 호출이 계속 실패하는 경우, 상태적으로 모노 레포가 계속해서 보조 노드에 뒤처지게 될 수 있습니다. 그러면 모든 트래픽이 주 노드로 이동하게 됩니다.
이러한 실패한 프록시 쓰기의 한 가지 이유는 Git $GIT_DIR/packed-refs
파일의 알려진 문제입니다. 파일에서 항목을 제거하려면 파일을 잠그어야 하며, 이는 동시에 삭제가 발생할 때 실패할 수 있는 레이스 조건을 유발할 수 있습니다.
GitLab의 엔지니어들은 레퍼런스 삭제를 일괄로 처리하기 위해 완화 조치를 개발했습니다.
다음과 같은 기능 플래그를 활성화하여 GitLab이 레퍼런스 삭제를 일괄 처리할 수 있도록합니다. 이러한 기능 플래그를 활성화하려면 다운타임이 필요하지 않습니다.
merge_request_cleanup_ref_worker_async
pipeline_cleanup_ref_worker_async
pipeline_delete_gitaly_refs_in_batches
merge_request_delete_gitaly_refs_in_batches
에픽 4220은 GitLab에 RefTable 지원을 추가하는 것을 제안하며, 이는 장기적인 솔루션으로 간주됩니다.