모노레포의 성능 문제에 대한 이러한 제안을 검토합니다.

git clone 또는 git fetch 중 느림#

클론 및 페치의 느림에는 몇 가지 주요 원인이 있습니다.

높은 CPU 사용률#

Gitaly 노드의 CPU 사용률이 높으면 특정 값을 필터링하여 클론에서 얼마나 많은 CPU를 사용하는지 확인할 수 있습니다.

특히 command.cpu_time_ms 필드는 클론 및 페치에서 얼마나 많은 CPU를 사용하는지 나타낼 수 있습니다.

대부분의 경우 서버 부하의 대부분은 클론 및 페치 중에 시작되는 git-pack-objects 프로세스에서 발생합니다. 모노레포는 종종 매우 바쁘고 CI/CD 시스템은 서버에 많은 클론 및 페치 명령을 보냅니다.

높은 CPU 사용률은 느린 성능의 일반적인 원인입니다. 다음과 같은 상호 배타적이지 않은 원인이 가능합니다:

• Gitaly가 처리하기에 너무 많은 클론.
• Gitaly 클러스터(Praefect)의 읽기 분배 불량.

원인: 너무 많은 대형 클론#

Gitaly가 처리하기에 너무 많은 대형 클론이 있을 수 있습니다. Gitaly는 여러 요인으로 인해 따라가기 어려울 수 있습니다:

• 저장소의 크기.
• 클론 및 페치의 볼륨.
• CPU 용량 부족.

Gitaly가 많은 대형 클론을 처리하는 데 도움을 주기 위해 다음과 같은 최적화 전략을 통해 Gitaly 서버의 부담을 줄여야 할 수 있습니다:

• git-pack-objects가 해야 하는 작업을 줄이기 위해 pack-objects-cache를 켜세요.
• CI/CD 설정에서 Git 전략을 clone에서 fetch 또는 none으로 변경하세요.
• 테스트에 태그가 필요하지 않는 한 태그 페치 중지.
• 가능한 경우 얕은 클론 사용.

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

원인: 읽기 분배 불량#

Gitaly 클러스터(Praefect)에서 읽기 분배가 불량할 수 있습니다.

클러스터 전체에 분배되는 대신 대부분의 읽기 트래픽이 기본 Gitaly 노드로 가는지 관찰하려면 읽기 분배 Prometheus 메트릭을 사용하세요.

보조 Gitaly 노드가 많은 트래픽을 받지 못하는 경우 보조 노드가 지속적으로 동기화되지 않을 수 있습니다. 이 문제는 모노레포에서 더 악화됩니다.

모노레포는 종종 크고 바쁩니다. 이로 인해 두 가지 효과가 발생합니다. 첫째, 모노레포에 자주 푸시되고 많은 CI job이 실행됩니다. 브랜치 삭제와 같은 쓰기 작업이 보조 노드에 대한 프록시 호출을 실패시키는 경우가 있을 수 있습니다. 이렇게 하면 보조 노드가 결국 따라잡을 수 있도록 Gitaly 클러스터(Praefect)에서 복제 job이 트리거됩니다.

복제 job은 본질적으로 보조 노드에서 기본 노드로의 git fetch이며, 모노레포는 종종 매우 크기 때문에 이 페치는 오랜 시간이 걸릴 수 있습니다.

이전 복제 job이 완료되기 전에 다음 호출이 실패하고 이것이 계속 발생하면 모노레포가 보조 노드에서 지속적으로 뒤처진 상태로 끝날 수 있습니다. 이로 인해 모든 트래픽이 기본 노드로 가게 됩니다.

이러한 실패한 프록시된 쓰기의 한 가지 이유는 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 지원을 추가할 것을 제안하며, 이는 장기적인 해결책으로 간주됩니다.