- イシュー、マージリクエスト、コミットごとのコメント数
- イシュー、マージリクエスト、エピックに関するコメントや説明のサイズ
- マイルストーン概要のイシュー数
- Gitプッシュごとのパイプライン数
- アクティビティ履歴の保持
- 組み込みメトリクス数
- webhook数
- 自動返信メールからの受信
- Sentry から Error Tracking 経由で送信されるデータ量
- オフセットベースのページネーションで REST API 経由で許可されるオフセットの最大値
- CI/CDの限界
- インスタンスのモニタリングとメトリクス
- デプロイボードの環境データ
- マージリクエストレポート
- 高度なグローバル検索制限
- ウィキ制限
- スニペット制限
- 設計管理の限界
- イベントの限界に挑戦
GitLabアプリケーションの制限
GitLabは、多くの大規模なアプリケーションと同様に、最低限のパフォーマンスクオリティを維持するために、特定の機能に制限を課しています。 いくつかの機能を無制限に許可すると、セキュリティやパフォーマンス、データに影響を与えたり、アプリケーションに割り当てられたリソースを使い果たしてしまう可能性があります。
イシュー、マージリクエスト、コミットごとのコメント数
GitLab 12.4で導入されました。
イシューやマージリクエスト、コミットに対して投稿できるコメントの数には制限があります。 制限に達した場合でも、システムノートを追加することでイベントの履歴は失われませんが、ユーザーが投稿したコメントは失敗します。
- 最大コメント数:5.000
イシュー、マージリクエスト、エピックに関するコメントや説明のサイズ
GitLab 12.2で導入されました。
イシュー、マージリクエスト、エピックに対するコメントや説明のサイズには制限があります。 制限を超えるテキストを追加しようとするとエラーとなり、アイテムは作成されません。
今後、この上限がより低い数値に変更される可能性もあります。
- 最大サイズ:~100万文字/~1MB
マイルストーン概要のイシュー数
GitLab 12.10 で導入されました。
マイルストーンの概要ページにロードされるイシューの最大数は3000です。 制限数を超えると、ページにアラートが表示され、マイルストーン内のすべてのイシューのページ分割リストへのリンクが表示されます。
- 制限:3000イシュー
Gitプッシュごとのパイプライン数
GitLab 11.10 で導入されました。
1回のプッシュで作成できるパイプラインの数は4です。これは、git push --all
またはgit push --mirror
を使用する際に、誤ってパイプラインが作成されるのを防ぐためです。
詳しくはCIドキュメントをご覧ください。
アクティビティ履歴の保持
GitLab 8.12で導入されました。
プロジェクトや個人のプロフィールのアクティビティ履歴は、GitLab 11.4までは1年、GitLab 12.4では3年に制限されていました。
組み込みメトリクス数
GitLab 12.7から導入されました。
パフォーマンス上、GFMにメトリクスを埋め込むには限界があります。
- 最大制限:100エンベッド
webhook数
GitLab.comでは、1プロジェクト、1グループあたりの最大webhook数に制限があります。
セルフマネージドインストールでこの制限を設定するには、GitLabRailsコンソールで以下を実行します:
# If limits don't exist for the default plan, you can create one with:
# Plan.default.create_limits!
# For project webhooks
Plan.default.actual_limits.update!(project_hooks: 100)
# For group webhooks
Plan.default.actual_limits.update!(group_hooks: 100)
0
に設定します。自動返信メールからの受信
GitLab 12.4で導入されました。
GitLab はX-Autoreply
ヘッダを探すことで、自動返信メールから送信されたすべての受信メールを無視します。 このようなメールはイシューへのコメントやマージリクエストを作成しません。
Sentry から Error Tracking 経由で送信されるデータ量
GitLab 12.6 で導入されました。
GitLabに送信されるSentryペイロードには、セキュリティ上の理由とメモリ消費を制限するために、最大1MBの制限があります。
オフセットベースのページネーションで REST API 経由で許可されるオフセットの最大値
GitLab 13.0から導入されました。
REST API でオフセットベースのページ分割を使用する場合は、 結果のセットへのオフセット要求の最大値に制限があります。 この制限は、キーセットベースのページ分割をサポートしているエンドポイントにのみ適用されます。 ページ分割のオプションについての詳細は、API ドキュメントの ページ分割 のセクションを参照ください。
セルフマネージドインストールでこの制限を設定するには、GitLabRailsコンソールで以下を実行します:
# If limits don't exist for the default plan, you can create one with:
# Plan.default.create_limits!
Plan.default.actual_limits.update!(offset_pagination_limit: 10000)
- デフォルトのオフセットのページネーション制限:50000
0
に設定します。CI/CDの限界
アクティブパイプラインのジョブ数
GitLab 12.6 で導入されました。
アクティブなパイプラインのジョブ総数は、プロジェクトごとに制限できます。 この制限は、新しいパイプラインが作成されるたびに確認されます。 アクティブなパイプラインとは、次のいずれかの状態にあるパイプラインのことです:
created
pending
running
新しいパイプラインによってジョブの総数が制限を超える場合、パイプラインはjob_activity_limit_exceeded
エラーで失敗します。
- GitLab.comでは、プランごとに異なる制限が定義されており、その制限値はそのプランのすべてのプロジェクトに影響します。
-
GitLab Starterティア以上のセルフマネージドインストールでは、この制限はすべてのプロジェクトに影響する
default
プランに対して定義されます。 この制限はデフォルトでは無効になっています。
セルフマネージドインストールでこの制限を設定するには、GitLabRailsコンソールで以下を実行します:
# If limits don't exist for the default plan, you can create one with:
# Plan.default.create_limits!
Plan.default.actual_limits.update!(ci_active_jobs: 500)
0
に設定します。プロジェクトのCI/CDサブスクリプション数
GitLab 12.9で導入されました。
プロジェクトごとにサブスクリプションの総数を制限することができます。 この制限は、新しいサブスクリプションが作成されるたびにチェックされます。
新規の購読によって購読総数が制限を超える場合、その購読は無効とみなされます。
- GitLab.comでは、プランごとに異なる制限が定義されており、その制限値はそのプランのすべてのプロジェクトに影響します。
- GitLab Starterティア以上のセルフマネージドインストールでは、この制限はすべてのプロジェクトに影響する
default
プランに対して定義されます。
セルフマネージドインストールでこの制限を設定するには、GitLabRailsコンソールで以下を実行します:
Plan.default.actual_limits.update!(ci_project_subscriptions: 500)
0
に設定します。パイプラインスケジュール数
GitLab 12.10 で導入されました。
プロジェクトごとにパイプラインスケジュールの総数を制限することができます。 この制限は、新しいパイプラインスケジュールを作成するたびにチェックされます。 新しいパイプラインスケジュールによってパイプラインスケジュールの総数が制限を超える場合は、パイプラインスケジュールは作成されません。
GitLab.comでは、プランごとに異なる制限が定義されており、そのプランの下にあるすべてのプロジェクトに影響します。
セルフマネージドインスタンス(GitLab Starterまたはそれ以上のティア)では、この制限はすべてのプロジェクトに影響するdefault
プランに対して定義されます。デフォルトでは、制限はありません。
セルフマネージドインストールでこの制限を設定するには、GitLabRailsコンソールで以下を実行します:
Plan.default.actual_limits.update!(ci_pipeline_schedules: 100)
インスタンスレベル変数の数
GitLab 13.1で導入されました。
インスタンスレベルのCI/CD変数の総数はインスタンスレベルで制限されています。 この制限は、新しいインスタンスレベルの変数が作成されるたびにチェックされます。 新しい変数によって変数の総数が制限を超える場合、新しい変数は作成されません。
セルフマネージドインスタンスでは、この上限はdefault
プランに対して定義されます。デフォルトでは、この上限は25
に設定されます。
セルフマネージドインストールでこの制限を新しい値に更新するには、GitLabRailsコンソールで以下を実行します:
Plan.default.actual_limits.update!(ci_instance_level_variables: 30)
インスタンスのモニタリングとメトリクス
インシデント管理インバウンドアラート制限
GitLab 12.5で導入されました。
インシデントの受信アラートを制限することで、一定期間内に作成できるアラート(イシュー)の数を減らすことができ、重複するイシューでインシデント対応担当者に過負荷がかかるのを防ぐことができます。 以下の方法でアラートの量を減らすことができます:
- プロジェクトごとの期間あたりの最大リクエスト数は、デフォルトでは3600秒です。
- レート制限の期間を秒単位で指定。デフォルトでは3600秒。
Prometheus アラート JSON ペイロード
GitLab 12.6 で導入されました。
notify.json
エンドポイントに送信される Prometheus アラートペイロードのサイズは 1 MB に制限されています。
汎用アラートJSONペイロード
GitLab 12.4で導入されました。
notify.json
エンドポイントに送信されるアラートペイロードのサイズは1MBに制限されています。
メトリクスダッシュボードのYAMLファイル
GitLab 13.2 で導入されました。
解析されたメトリクス・ダッシュボード YAML ファイルが占有するメモリは、1 MB を超えることはできません。
各 YAML ファイルの最大深度は 100 に制限されます。 YAML ファイルの最大深度は、もっともネストされたキーのネスト量です。 もっともネストされたキーのパス上の各ハッシュと配列は、その深度にカウントされます。 たとえば、次の YAML のもっともネストされたキーの深度は 7 です:
dashboard: 'Test dashboard'
links:
- title: Link 1
url: https://gitlab.com
panel_groups:
- group: Group A
priority: 1
panels:
- title: "Super Chart A1"
type: "area-chart"
y_label: "y_label"
weight: 1
max_value: 1
metrics:
- id: metric_a1
query_range: 'query'
unit: unit
label: Legend Label
デプロイボードの環境データ
Deploy BoardsはKubernetesからポッドやデプロイに関する情報を読み込みます。 ただし、Kubernetesから読み込んだ特定の環境の10MBを超えるデータは表示されません。
マージリクエストレポート
20MBを超えるレポーターは読み込まれません。 影響を受けるレポート
高度なグローバル検索制限
最大フィールド長
GitLab 12.8で導入されました。
グローバル検索でインデックスされるテキストフィールドの内容に上限を設定することができます。 上限を設定することで、インデックス処理の負荷を軽減することができます。 テキストフィールドがこの上限を超えた場合、テキストはこの文字数まで切り詰められ、残りはインデックスされないため、検索することができません。
- GitLab.comでは20000文字に制限されています。
- 自己管理インストールの場合、デフォルトでは無制限です。
この制限は、Elasticsearchを有効にする際に、セルフマネージドインストール用に設定することができます。
0
に設定します。ウィキ制限
スニペット制限
スニペット設定のドキュメントを参照してください。
設計管理の限界
デザイン管理の制限のセクションを参照してください。
イベントの限界に挑戦
Webhookとプロジェクトサービス
GitLab 12.4で導入されました。
一回のプッシュにおける変更 (ブランチまたはタグ) の総数。 変更が指定した上限を超えた場合、フックは実行されません。
詳しくはこちらのドキュメントをご覧ください:
アクティビティ
GitLab 12.4で導入されました。
個別のプッシュイベントが作成されるか、一括プッシュイベントが作成されるかを決定するための、1回のプッシュにおける変更(ブランチまたはタグ)の総数。
詳細については、プッシュイベントのアクティビティ制限と一括プッシュイベントのドキュメントを参照してください。