Gitaly는 구성 가능한 두 가지 유형의 타임아웃을 제공합니다.

• 호출 타임아웃. GitLab UI로 구성합니다.
• 협상 타임아웃. Gitaly 구성 파일로 구성합니다.

호출 타임아웃 구성#

장기 실행되는 Gitaly 호출이 불필요하게 리소스를 차지하지 않도록 다음 호출 타임아웃을 구성합니다.

사전 요구 사항:

• 관리자 액세스 권한.

호출 타임아웃을 구성하려면 다음 단계를 따릅니다.

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > Preferences를 선택합니다.
3. Gitaly timeouts 섹션을 확장합니다.
4. 필요에 따라 각 타임아웃을 설정합니다.

사용 가능한 호출 타임아웃#

Gitaly 작업 종류에 따라 서로 다른 호출 타임아웃을 사용할 수 있습니다.

기본적으로 Default 타임아웃은 57 초보다 높게 설정할 수 없습니다. 자세한 내용은 Gitaly 기본 타임아웃을 57초 이상으로 올릴 수 없는 문제를 참고합니다.

협상 타임아웃 구성#

다음 경우에는 협상 타임아웃을 늘려야 할 수 있습니다.

• 특히 큰 리포지터리를 다루는 경우.
• 이러한 명령을 병렬로 실행하는 경우.

다음 항목에 대해 협상 타임아웃을 구성할 수 있습니다.

• git-upload-pack(1). git fetch를 실행할 때 Gitaly 노드가 호출합니다.
• git-upload-archive(1). git archive --remote를 실행할 때 Gitaly 노드가 호출합니다.

이러한 타임아웃을 구성하려면 다음 단계를 따릅니다.

gitaly['configuration'] = {
    timeout: {
        upload_pack_negotiation: '10m',      # 10 minutes
        upload_archive_negotiation: '20m',   # 20 minutes
    }
}

[timeout]
upload_pack_negotiation = "10m"
upload_archive_negotiation = "20m"

값에는 Go의 ParseDuration 형식을 사용합니다.

이러한 타임아웃은 원격 Git 작업의 협상 단계에만 영향을 주며, 전체 전송에는 영향을 주지 않습니다.

Gitaly 클라이언트 재시도#

Gitaly는 때때로 짧은 시간 동안 사용할 수 없는 상태가 됩니다. 예를 들어 GitLab 업그레이드 중입니다. 특히 Kubernetes에서 실행하는 Gitaly는 Pod 시작과 재시작에 몇 초가 걸립니다.

짧은 사용 불가 구간에서 GitLab 이 클라이언트에 오류를 반환하지 않도록 Gitaly 클라이언트 재시도를 구성합니다. Gitaly 클라이언트 재시도가 구성된 상태에서 Gitaly를 사용할 수 없으면 Rails(GitLab 애플리케이션), Workhorse, GitLab Shell 같은 Gitaly 클라이언트가 지수 백오프 방식으로 요청을 재시도합니다.

구성할 수 있는 매개변수는 두 개입니다.

• max_attempts: 최대 재시도 횟수이며 2에서 5 사이입니다.
• max_backoff: 클라이언트가 재시도를 중단하기까지의 최대 시간입니다. 값은 1.4s 나 10s 같은 기간 문자열이어야 합니다.

백오프 배수는 2로 설정되며, 초기 백오프는 두 매개변수에서 도출됩니다.

구성 지침#

적절한 구성은 GitLab 인스턴스 구성과 이러한 상황이 발생했을 때 Gitaly가 사용 불가 상태로 머무는 시간에 따라 달라집니다.

• Kubernetes에서는 클라우드 공급자에 따라 Gitaly Pod가 시작되는 데 약 10~12초가 걸릴 수 있습니다. 이 시간에는 볼륨이 Pod에 연결되고 마운트되는 데 걸리는 시간이 포함됩니다.
• Linux 패키지 인스턴스에서는 Gitaly 재시작이 프로세스 재시작이므로 훨씬 빠르게 끝날 수 있습니다.

또한 Gitaly에는 정상 종료 타임아웃을 구성할 수 있다는 점도 고려합니다. Gitaly가 종료되는 동안 새 요청은 거부되지만 gRPC 서버는 다음 중 하나가 될 때까지 처리 중인 요청을 계속 처리합니다.

• 모든 요청이 처리됩니다.
• 종료 타임아웃이 만료됩니다.

이 정상 종료 타임아웃은 Gitaly가 새 요청을 받지 못하는 시간의 길이에 영향을 줄 수 있습니다.

max_backoff는 정상 종료 시간과 (재)시작 시간의 합과 같거나 그보다 큰 값으로 클라이언트 재시도를 구성합니다.

클라이언트 재시도 구성#

다음 구성은 Rails(GitLab 애플리케이션), Workhorse, GitLab Shell에 적용되며 모든 클라이언트에 동일한 구성이 적용됩니다.

제시된 값은 예시이며 지침으로 받아들이지 않습니다.

gitlab_rails['gitaly_client_max_attempts'] = 5
gitlab_rails['gitaly_client_max_backoff'] = '1.4s'

global:
  gitaly:
    client:
      maxAttempts: 5
      maxBackoff: '1.4s'

문제 해결#

Gitaly 타임아웃을 다룰 때 다음 문제가 발생할 수 있습니다.

Gitaly 기본 타임아웃을 57초 이상으로 올릴 수 없는 문제#

기본적으로 Default 타임아웃은 57 초보다 높게 올릴 수 없습니다. 타임아웃을 더 높게 설정하려고 하면 다음 유효성 검사 오류가 발생합니다.

Gitaly timeout default must be less than or equal to 57

이 제한은 서로 영향을 주는 세 가지 타임아웃에서 비롯됩니다.

• puma['worker_timeout']: 워커별 Puma 타임아웃입니다. 기본값은 60 초입니다. 자세한 내용은 워커 타임아웃 변경을 참고합니다.
• gitlab_rails['max_request_duration_seconds']#Gitaly Default 타임아웃을 제한하는 GitLab 애플리케이션 설정입니다. 기본값은 (worker_timeout * 0.95).ceil = 57 초입니다. 이 설정은 puma['worker_timeout']보다 반드시 작아야 합니다.
• GITLAB_RAILS_RACK_TIMEOUT: Rack::Timeout 미들웨어의 service_timeout 입니다. 기본값은 60 초입니다. 이 타임아웃은 나머지 두 값과 독립적이며, 다른 값이 어떻게 구성되어 있든 이 값에서 요청을 종료합니다.

Gitaly Default 타임아웃을 57초 이상으로 올리려면 세 값을 모두 함께 올려야 합니다. 예를 들어 Gitaly Default 타임아웃을 110 초로 허용하려면 다음 단계를 따릅니다.

1. /etc/gitlab/gitlab.rb를 편집합니다.

   puma['worker_timeout'] = 120
   gitlab_rails['max_request_duration_seconds'] = 114
   gitlab_rails['env'] = {
     'GITLAB_RAILS_RACK_TIMEOUT' => 120
   }
   

2. GitLab을 재구성합니다.

   sudo gitlab-ctl reconfigure
   

3. 오른쪽 상단에서 Admin을 선택합니다.

4. 왼쪽 사이드바에서 Settings > Preferences를 선택합니다.

5. Gitaly timeouts를 확장합니다.

6. Default timeout을 원하는 새 값(max_request_duration_seconds 이하)으로 설정합니다.

   약간의 여유를 두기를 권장합니다. 내장 기본값은 5% 간격을 사용하므로 (max_request_duration_seconds = (worker_timeout * 0.95).ceil), Puma가 워커 타임아웃에 도달하기 전에 Rails 요청 기한이 먼저 걸립니다.

   GITLAB_RAILS_RACK_TIMEOUT 만으로는 Gitaly 상한이 올라가지 않습니다. 애플리케이션 설정 유효성 검사기가 참조하는 값은 Settings.gitlab.max_request_duration_seconds 이며, 이 값은 gitlab_rails['max_request_duration_seconds']로 설정됩니다. 다만 GITLAB_RAILS_RACK_TIMEOUT을 기본값인 60으로 두면 Rack 미들웨어가 긴 Gitaly 호출을 포함해 60초를 넘는 모든 요청을 완료되기 전에 종료합니다.