内部許可API

internal/allowed エンドポイントは、ユーザーが Git リポジトリに対して特定のオペレーションを実行する権限があるかどうかを調べます。このエンドポイントは、次のような複数のチェックを行います：

  • ブランチ名やタグ名が正しいかどうか。
  • ユーザーにそのアクションを実行する権限があるかどうか。

エンドポイントの定義

内部 API エンドポイントはlib/api/internalで定義されており、/allowed パスはlib/api/internal/base.rbにあります。

エンドポイント

internal/allowed が呼び出されます：

  • リポジトリにプッシュします。
  • GitLab ユーザーインターフェイスを通して、リポジトリに対してアクションを実行します。

Gitalyは通常このエンドポイントを呼び出します。これは、API の外部ユーザーによってではなく、内部的に（アプリケーションの他の部分によって）呼び出されるだけです。

プッシュチェック

internal/allowed フローの重要な部分は、EE::Gitlab::Checks::PushRuleCheck へのコールです：

  • EE::Gitlab::Checks::PushRules::CommitCheck
  • EE::Gitlab::Checks::PushRules::TagCheck
  • EE::Gitlab::Checks::PushRules::BranchCheck
  • EE::Gitlab::Checks::PushRules::FileSizeCheck

再帰

Gitalyから呼び出されたRPCのいくつかはinternal/allowed 、それ自体が.RPCに呼び戻さ internal/allowedれます。 これらの呼び出しは、元のリクエストと関連付けられます。Gitalyは権限をRailsアプリケーションに依存しており、自分自身では権限モデルを保持していません。

これらの呼び出しは、最初のリクエストとは異なる形でログに表示されます。例

このエンドポイントは再帰的に呼び出される可能性があるため、 このエンドポイントの遅いパフォーマンスは指数関数的なパフォーマンスへの 影響をもたらします。このドキュメントは実際にそのパフォーマンスに関する調査から適応されたものです。

既知のパフォーマンスに関するイシュー

参考文献

Git リポジトリのrefs の数は、git そのリポジトリを呼び出すコマンドの gitパフォーマンスに顕著な影響を与えます。git Gitaly RPC も同様に影響を受けます。特定の gitコマンドはすべてのRefをスキャンし、それらのコマンドの速度に顕著な影響を与えます。

internal/allowed エンドポイントでは、RPC 呼び出しの再帰的な性質により、ref 数がパフォーマンスに指数関数的な影響を与えます。

環境 refs

古い環境参照は、過剰な参照がパフォーマンスのイシューを引き起こす一般的な例です。古い環境参照は、自動的にクリアされないため、混雑しているリポジトリでは何万にもなることがあります。

ぶら下がった参照

ぶら下がり参照は、オブジェクトプールからオブジェクトが誤って削除されるのを防ぐために作成されます。これらの参照は大量に存在する可能性があり、パフォーマンスに影響を与える可能性があります。このイシューに関する既存の議論については、gitaly#1900 を参照してください。このイシューは、古い環境参照よりも影響が小さいようです。

リポジトリプール

GitLabでフォークが作成されると、中央のプールリポジトリが作成され、フォークはそれにリンクされます。このプールリポジトリは、他のフォークと共通のデータを保存することで、データの重複を防ぎます。しかし、プールリポジトリは標準リポジトリと同じようにクリーンアップされず、refs問題が発生しやすくなります。

フィーチャーフラグ

並列プッシュ・チェック

フラグ: セルフマネジメントのGitLabでは、デフォルトではこの機能は利用できません。利用可能にするには、管理者がparallel_push_checks. parallel_push_checksNETフラグという機能フラグを有効にします。parallel_push_checksGitLab.comでは、デフォルトではこの機能は利用できません。プロジェクトごとに利用できるようにするには、GitLab.comの管理 parallel_push_checks者に.GitLab.comというparallel_push_checks機能フラグを有効に parallel_push_checksするよう依頼してください。本番環境ではこの機能を使用しないでください。

この実験的な機能フラグを使うと、エンドポイントが複数の RPC を同時に実行できるようになり、全体の所要時間がおよそ半分に短縮されます。この時間短縮はスレッドによって実現されており、大規模な場合には副作用の可能性があります。GitLab.com では、この機能フラグはgitlab-org/gitlab とgitlab-com/www-gitlab-com プロジェクトでのみ有効です。これがないと、これらのプロジェクトではエンドポイントへのリクエストがタイムアウトしてしまいます。この機能がGitLab.com全体にデプロイされたとき、いくつかのプッシュが失敗しました。おそらく、データベース接続プールのようなリソースを使い果たしたためだと思われます。

この機能フラグを有効にするのはタイムアウトが発生する場合のみとし、特定のプロジェクトでのみ有効にすることを推奨します。