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

• 호출 타임아웃: GitLab UI를 사용하여 구성합니다.
• 협상 타임아웃: Gitaly 구성 파일을 사용하여 구성합니다.

호출 타임아웃 구성#

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

사전 요구 사항:

• 관리자 액세스 권한.

호출 타임아웃을 구성하려면:

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

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

다양한 Gitaly 작업에 대해 서로 다른 호출 타임아웃을 사용할 수 있습니다.

기본적으로 기본 타임아웃은 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 시작 및 재시작이 몇 초가 걸립니다.

Gitaly가 잠시 사용 불가능할 때 클라이언트에 오류가 반환되는 것을 방지하려면 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초 이상으로 올릴 수 없음#

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

Gitaly timeout default must be less than or equal to 57

이 제한은 세 가지 상호 작용하는 타임아웃에 의해 부과됩니다:

• puma['worker_timeout']: 워커당 Puma 타임아웃. 기본값은 60초입니다. 자세한 내용은 워커 타임아웃 변경을 참조하세요.

• gitlab_rails['max_request_duration_seconds']: Gitaly 기본 타임아웃을 제한하는 GitLab 애플리케이션 설정. 기본값은 (worker_timeout * 0.95).ceil = 57초입니다. 이 설정은 puma['worker_timeout']보다 엄격하게 작아야 합니다.

• GITLAB_RAILS_RACK_TIMEOUT: Rack::Timeout 미들웨어 service_timeout. 기본값은 60초입니다. 이 타임아웃은 다른 두 타임아웃과 독립적이며 다른 설정에 관계없이 이 값에서 요청을 종료합니다.

Gitaly 기본 타임아웃을 57초 이상으로 올리려면 세 가지 값을 모두 함께 올려야 합니다. 예를 들어 Gitaly 기본 타임아웃을 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
}

1. GitLab을 재구성합니다:

sudo gitlab-ctl reconfigure

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

2. 왼쪽 사이드바에서 설정 > 기본 설정을 선택합니다.

3. Gitaly 타임아웃을 확장합니다.

4. 기본 타임아웃을 새 원하는 값(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 미들웨어가 60초보다 긴 요청(긴 Gitaly 호출 포함)을 완료되기 전에 종료합니다.