모노 레포 성능 문제 해결

모노 레포에 대한 성능 문제에 대한 제안 사항을 검토하십시오.

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 노드로 대부분의 읽기 트래픽이 이동하는지 여부를 확인하려면 읽기 분배 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 지원을 추가하는 것을 제안하며, 이는 장기적인 솔루션으로 간주됩니다.