ドキュメントに関する現在のご利用体験についてお聞かせください。アンケートにご協力ください。

Gitalyタイムアウトとリトライ

プラン: Free、Premium、Ultimate
提供形態: GitLab Self-Managed

Gitalyは、設定可能な2種類のタイムアウトを提供します:

GitLabのUIを使用して設定される呼び出しタイムアウト。
Gitalyの設定ファイルを使用して設定されるネゴシエーションタイムアウト。

呼び出しタイムアウトの設定

長時間実行されるGitalyの呼び出しが不必要にリソースを占有しないように、以下の呼び出しタイムアウトを設定します。

前提条件:

管理者アクセス権。

呼び出しタイムアウトを設定するには:

右上隅で、管理者を選択します。
左サイドバーで、設定 > 設定を選択します。
Gitalyタイムアウトセクションを展開します。
必要に応じて各タイムアウトを設定します。

利用可能な呼び出しタイムアウト

異なるGitaly操作に対して、異なる呼び出しタイムアウトが利用可能です。

タイムアウト	デフォルト	説明
デフォルト	55秒	ほとんどのGitaly呼び出しに対するタイムアウト（`git` `fetch`および`push`操作、またはSidekiqジョブには適用されません）。例えば、リポジトリがディスク上に存在するかどうかを確認する場合などです。Webリクエストで行われたGitaly呼び出しが、リクエスト全体のタイムアウトを超えないようにします。Puma用に設定できるワーカータイムアウトよりも短くする必要があります。Gitalyの呼び出しタイムアウトがワーカータイムアウトを超えた場合、ワーカーを終了する必要がないように、ワーカータイムアウトの残り時間が使用されます。
高速	10秒	リクエストで複数回使用されることもある高速なGitaly操作のタイムアウト。例えば、リポジトリがディスク上に存在するかどうかを確認する場合などです。高速な操作がこのしきい値を超えると、ストレージシャードに問題がある可能性があります。フェイルファストは、GitLabインスタンスの安定性を維持するのに役立ちます。
中程度	30秒	高速であるべきGitaly操作（リクエスト内で発生する可能性あり）で、できればリクエスト内で複数回使用されない場合のタイムアウト。例えば、blobを読み込む場合などです。デフォルトと高速の間に設定されるべきタイムアウト。

デフォルトでは、デフォルトのタイムアウトを57秒より高く設定することはできません。詳細については、Gitalyのデフォルトタイムアウトを57秒より高くできないを参照してください。

ネゴシエーションタイムアウトの設定

ネゴシエーションタイムアウトを増やす必要がある場合があります:

特に大きなリポジトリの場合。
これらのコマンドを並行して実行する場合。

ネゴシエーションタイムアウトは、以下に対して設定できます:

git-upload-pack(1)。git fetchを実行すると、Gitalyノードによって呼び出されます。
git-upload-archive(1)。git archive --remoteを実行すると、Gitalyノードによって呼び出されます。

これらのタイムアウトを設定するには:

/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_archive_negotiation = "20m"

値には、GoにおけるParseDurationの形式を使用します。

これらのタイムアウトは、リモートGit操作のネゴシエーションフェーズのみに影響し、転送全体には影響しません。

Gitalyクライアントのリトライ

Gitalyが一時的に利用できなくなることがあります。例えば、GitLabのアップグレード中などです。特にKubernetes上のGitalyでは、ポッドの起動と再起動に数秒かかる場合があります。

GitLabが一時的に利用できない場合にクライアントにエラーを返すのを防ぐため、Gitalyクライアントのリトライを設定します。Gitalyクライアントのリトライが設定されており、Gitalyが利用できない場合、Rails (GitLabアプリケーション)、Workhorse、GitLab ShellなどのGitalyクライアントは、指数関数的なバックオフ方式でリクエストをリトライします。

2つのパラメータを設定できます:

max_attempts: 2から5の間の最大リトライ試行回数。
max_backoff: クライアントがリトライを停止するまでの最大時間。値は、1.4sまたは10sのような期間文字列である必要があります。

バックオフ乗数は2に設定され、初期バックオフは2つのパラメータから導出されます。

設定ガイドライン

適切な設定は、GitLabインスタンスの設定と、そのようなイベントが発生した際にGitalyが利用できない期間によって異なります:

Kubernetes上では、Gitalyポッドの起動には、クラウドプロバイダーによって約10～12秒かかる場合があります。この時間には、ポッドにボリュームがアタッチおよびマウントされるまでの時間が含まれます。
Linuxパッケージインスタンスの場合、Gitalyの再起動はプロセス再起動であるため、Gitalyははるかに速く再起動する可能性があります。

また、Gitalyはグレースフルシャットダウンタイムアウトを設定できることも念頭に置いてください。Gitalyがシャットダウンしている間、新しいリクエストは拒否されますが、gRPCサーバーは以下のいずれかになるまで進行中のリクエストを処理し続けます:

すべて処理されます。
シャットダウンタイムアウトが経過します。

このグレースフルシャットダウンタイムアウトは、新しいリクエストに対してGitalyが利用できない期間に影響を与える可能性があります。

クライアントリトライをmax_backoffで設定する必要があります。これは、グレースフルシャットダウンと（再）起動時間の合計以上です。

クライアントリトライの設定

以下の設定は、Rails (GitLabアプリケーション)、Workhorse、およびGitLab Shellに適用され、同じ設定がすべてのクライアントに適用されます。

提供される値は例であり、ガイドラインとして扱わないでください。

これらの設定でgitlab.rbファイルを更新します:

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

これらの設定でvalues.ymlファイルを更新します:

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

トラブルシューティング

Gitalyタイムアウトで作業する際に、以下の問題に遭遇する可能性があります。

Gitalyのデフォルトタイムアウトを57秒より高くできない

必要な場合にのみこれらの値を上げてください。ワーカータイムアウトが高いほど、低速または停止したリクエストがPumaワーカーをより長く保持し、インスタンスの容量を削減します。Gitalyのデフォルトタイムアウトを上げる一般的な理由としては、低速なストレージ上の非常に大きなリポジトリ、高コストな差分または比較ビュー、または劣化したGitalyクラスターノードなどが挙げられます。インポート、ミラー、またはハウスキーピングなどのバックグラウンド作業の場合、この上限に制約されないSidekiqへのオフロードを推奨します。

デフォルトでは、デフォルトのタイムアウトを57秒より高くすることはできません。タイムアウトを高く設定しようとすると、以下の検証エラーが発生します:

Gitaly timeout default must be less than or equal to 57

この制限は、相互作用する3つのタイムアウトによって課せられます:

puma['worker_timeout']: ワーカーごとのPumaタイムアウト。デフォルトは60秒です。詳細については、ワーカータイムアウトの変更を参照してください。
gitlab_rails['max_request_duration_seconds']#GitLabアプリケーション設定。Gitalyデフォルトタイムアウトを制限します。デフォルトは(worker_timeout * 0.95).ceil = 57秒です。この設定は、puma['worker_timeout']より厳密に小さい必要があります。
GITLAB_RAILS_RACK_TIMEOUT: Rack::Timeoutミドルウェアservice_timeout。デフォルトは60秒です。このタイムアウトは他の2つとは独立しており、他の設定にかかわらず、この値でリクエストを終了します。

Gitalyのデフォルトタイムアウトを57秒より高くするには、3つの値をすべて一緒に上げる必要があります。例えば、Gitalyのデフォルトタイムアウトを110秒にするには:

/etc/gitlab/gitlab.rbを編集します:

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

GitLabを再設定します:
```
sudo gitlab-ctl reconfigure
```
右上隅で、管理者を選択します。
左サイドバーで、設定 > 設定を選択します。
Gitalyタイムアウトを展開します。
デフォルトのタイムアウトを新しい希望する値に設定します（最大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秒を超えるすべてのリクエストを終了させます。