Gitaly 타임아웃 및 재시도

GitLab Self-Managed에서 Gitaly 호출 타임아웃, 협상 타임아웃, 클라이언트 재시도를 구성하는 방법을 설명합니다.

Gitaly 는 두 가지 유형의 구성 가능한 타임아웃을 제공합니다: 호출 타임아웃: GitLab UI를 사용하여 구성합니다. 협상 타임아웃: Gitaly 구성 파일을 사용하여 구성합니다. 호출 타임아웃 구성 # 장기 실행되는 Gitaly 호출이 불필요하게 리소스를 차지하지 않도록 다음 호출 타임아웃을 구성합니다. 사전 요구 사항: 관리자 액세스 권한. 호출 타임아웃을 구성하려면: 오른쪽 상단에서 관리자 를 선택합니다. 설정 > 기본 설정 을 선택합니다. Gitaly 타임아웃 섹션을 확장합니다. 필요에 따라 각 타임아웃을 설정합니다. 사용 가능한 호출 타임아웃 # 다양한 Gitaly 작업에 대해 서로 다른 호출 타임아웃을 사용할 수 있습니다. 타임아웃 기본값 설명 기본 55초 대부분의 Gitaly 호출에 대한 타임아웃( git fetch 및 push 작업 또는 Sidekiq 잡에는 적용되지 않음). 예를 들어 저장소가 디스크에 있는지 확인하는 경우. 웹 요청에서 이루어진 Gitaly 호출이 전체 요청 타임아웃을 초과할 수 없도록 합니다. Puma 에 구성할 수 있는 워커 타임아웃 보다 짧아야 합니다. Gitaly 호출 타임아웃이 워커 타임아웃을 초과하면 워커를 종료하지 않기 위해 워커 타임아웃의 남은 시간이 사용됩니다. 빠름 10초 요청에서 사용되는 빠른 Gitaly 작업에 대한 타임아웃(때로는 여러 번). 예를 들어 저장소가 디스크에 있는지 확인하는 경우. 빠른 작업이 이 임계값을 초과하면 스토리지 샤드에 문제가 있을 수 있습니다. 빠른 실패는 GitLab 인스턴스의 안정성을 유지하는 데 도움이 됩니다. 중간 30초 빠르게 처리해야 하지만(요청에서 가능하면) 요청에서 여러 번 사용하지 않는 것이 좋은 Gitaly 작업에 대한 타임아웃. 예를 들어 블롭 로딩. 기본과 빠름 사이로 설정해야 합니다. 협상 타임아웃 구성 # 히스토리 GitLab 16.5에서 도입 되었습니다. 다음의 경우 협상 타임아웃을 늘려야 할 수 있습니다: 특히 큰 저장소의 경우. 이러한 명령을 병렬로 실행하는 경우. 다음에 대한 협상 타임아웃을 구성할 수 있습니다: git-upload-pack(1) : git fetch 를 실행할 때 Gitaly 노드에서 호출됩니다. git-upload-archive(1) : git archive --remote 를 실행할 때 Gitaly 노드에서 호출됩니다. 이러한 타임아웃을 구성하려면: Linux package (Omnibus) Self-compiled (source) /etc/gitlab/gitlab.rb 를 편집합니다: gitaly[ 'configuration' ] = { timeout: { upload_pack_negotiation: '10m' , # 10 minutes upload_archive_negotiation: '20m' , # 20 minutes } } /home/git/gitaly/config.toml 을 편집합니다: [timeout] upload_pack_negotiation = "10m" upload_archiv