모노 레포 성능 문제 해결

모노 레포의 성능 문제에 대한 제언을 검토하세요.

git clone 또는 git fetch 중 느린 속도

복제 및 가져오기 작업의 느린 속도에 대한 주요 원인이 몇 가지 있습니다.

고 CPU 활용

Gitaly 노드의 CPU 활용이 높은 경우 특정 값에 대한 필터링을 확인하여 복제 작업으로부터 소비되는 CPU 양을 확인할 수 있습니다.

특히 command.cpu_time_ms 필드는 복제 및 가져오기 작업으로 소비되는 CPU 양을 나타낼 수 있습니다.

대부분의 경우, 서버 부하의 주된 부분은 복제 및 가져오기 작업 중에 시작되는 git-pack-objects 프로세스에서 생성됩니다. 모노 레포는 종종 매우 바쁘며 CI/CD 시스템은 많은 복제 및 가져오기 명령을 서버에 보냅니다.

고 CPU 활용은 느린 성능의 일반적인 원인입니다. 다음은 상호 배타적인 원인입니다:

원인: 너무 많은 대규모 복제

Gitaly가 처리하기에 너무 많은 대규모 복제가 있을 수 있습니다. Gitaly는 다음과 같은 여러 요소 때문에 따라잡기 어려울 수 있습니다:

  • 리포지터리의 크기.
  • 복제 및 가져오기의 양.
  • CPU 용량 부족.

Gitaly가 많은 대규모 복제를 처리하도록 돕기 위해 다음과 같은 최적화 전략을 통해 Gitaly 서버의 부담을 줄일 필요가 있을 수 있습니다:

다른 옵션으로는 Gitaly 서버의 CPU 용량을 늘리는 것입니다.

원인: 부적절한 읽기 분산

Gitaly 클러스터에서 부적절한 읽기 분산이 있을 수 있습니다.

클러스터 전체에서 읽기 트래픽의 대부분이 주 Gitaly 노드에 몰리는지 확인하려면 읽기 분산 Prometheu 메트릭을 사용합니다.

보조 Gitaly 노드에 트래픽이 거의 없는 경우, 보조 노드가 계속해서 동기화되지 않은 상태일 수 있습니다. 이 문제는 모노 레포에서 악화됩니다.

모노 레포는 종종 크고 바쁩니다. 이로 인해 두 가지 효과가 발생합니다. 첫째, 모노 레포는 자주 푸시되며 많은 CI 작업을 실행합니다. 가끔은 브랜치를 삭제하는 등의 쓰기 작업이 보조 노드에 대한 프록시 호출에 실패할 수 있습니다. 이로 인해 Gitaly 클러스터에서 복제 작업이 트리거됩니다. 결과적으로 보조 노드가 결국 따라잡습니다.

이 복제 작업은 본질적으로 보조 노드에서 주 노드로의 git fetch입니다. 모노 레포가 종종 매우 크기 때문에 이러한 가져오기는 오랜 시간이 걸릴 수 있습니다.

이전 복제 작업이 완료되기 전에 다음 호출이 계속 실패하면, 계속해서 주 노드로의 모노 레포가 항상 뒤쳐진 상태가 될 수 있습니다.

본인 참조 삭제와 관련하여 발생한 이미 알려진 문제로 인해 이러한 실패한 프록시 쓰기가 있을 수 있습니다. $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 지원을 추가하는 것을 제안하며, 이는 장기적인 해결책으로 간주됩니다.