GitLab 应用限制
- 层级:Free、Premium、Ultimate
- 产品类型:GitLab 自托管
GitLab 与大多数大型应用程序一样,在某些功能上实施限制以维持最低性能质量。若允许某些功能无限制使用,可能会影响安全性、性能、数据,甚至耗尽应用程序分配的资源。
实例配置
在实例配置页面中,你可以找到关于当前 GitLab 实例所用设置的一些信息。
根据你配置的限制,你可以看到:
- SSH 主机密钥信息
- CI/CD 限制
- GitLab Pages 限制
- 包注册表限制
- 速率限制
- 大小限制
由于该页面对所有人均可见,未认证用户仅能看到与其相关的信息。
要访问实例配置页面:
- 在左侧边栏中选择 帮助( )> 帮助。
- 在帮助页面中,选择 检查当前实例配置。
直接 URL 为 <gitlab_url>/help/instance_configuration。对于 GitLab.com,你可以访问 https://gitlab.com/help/instance_configuration。
速率限制
速率限制可用于提升 GitLab 的安全性与稳定性。
阅读更多关于 配置速率限制 的内容。
问题创建
此设置限制对问题创建端点的请求频率。
阅读更多关于 问题创建速率限制 的内容。
- 默认速率限制:默认禁用。
按用户或 IP
此设置限制每个用户或 IP 的请求频率。
阅读更多关于 用户与 IP 速率限制 的内容。
- 默认速率限制:默认禁用。
按原始端点
此设置限制每个端点的请求频率。
阅读更多关于 原始端点速率限制 的内容。
- 默认速率限制:每个项目、每次提交及每个文件路径下 300 个请求。
按受保护路径
此设置限制特定路径上的请求频率。
GitLab 默认对以下路径进行速率限制:
'/users/password',
'/users/sign_in',
'/api/#{API::API.version}/session.json',
'/api/#{API::API.version}/session',
'/users',
'/users/confirmation',
'/unsubscribes/',
'/import/github/personal_access_token',
'/admin/session'阅读更多关于 受保护路径速率限制 的内容。
- 默认速率限制:发出 10 次请求后,客户端必须等待 60 秒才能再次尝试。
包注册表
此设置限制包 API 上每个用户或 IP 的请求频率。更多信息,请参见 包注册表速率限制。
- 默认速率限制:默认禁用。
Git LFS
此设置限制每个用户的 Git LFS 请求频率。更多信息,请阅读 GitLab Git 大型文件存储(LFS)管理。
- 默认速率限制:默认禁用。
文件 API
此设置限制包 API 上每个用户或 IP 地址的请求频率。更多信息,请阅读 文件 API 速率限制。
- 默认速率限制:默认禁用。
已弃用的 API 端点
此设置限制已弃用的 API 端点上每个用户或 IP 地址的请求频率。更多信息,请阅读 已弃用 API 速率限制。
- 默认速率限制:默认禁用。
导入/导出
此设置限制群组和项目的导入/导出操作。
| 限制 | 默认值(每分钟每人) |
|---|---|
| 项目导入 | 6 |
| 项目导出 | 6 |
| 项目导出下载 | 1 |
| 群组导入 | 6 |
| 群组导出 | 6 |
| 群组导出下载 | 1 |
阅读更多关于 导入/导出速率限制 的内容。
成员邀请
限制每个群组层级每天允许的最大成员邀请数。
- GitLab.com:免费成员可每天邀请 20 名成员,Premium 试用版和 Ultimate 试用版成员可每天邀请 50 名成员。
- GitLab 自托管:邀请不受限制。
Webhook 速率限制
限制每个顶级命名空间每分钟调用 webhook 的次数。
此限制仅适用于项目和群组 webhook。
超出速率限制的调用会被记录到 auth.log 中。
若要在 GitLab 自托管实例中设置此限制,请在 GitLab Rails 控制台 中运行以下命令:
# 如果默认计划不存在限制,你可以通过以下方式创建:
# Plan.default.create_limits!
Plan.default.actual_limits.update!(web_hook_calls: 10)将限制设置为 0 可禁用该功能。
- 默认速率限制:禁用(无限制)。
搜索速率限制
此设置按如下方式限制搜索请求:
| 限制 | 默认值(每分钟请求数) |
|---|---|
| 认证用户 | 30 |
| 未认证用户 | 10 |
每分钟超出搜索速率限制的请求会返回以下错误:
此端点已被请求太多次。请稍后重试。自动补全用户的速率限制
此设置按如下方式限制自动补全用户的请求:
| 限制 | 默认值(每分钟请求数) |
|---|---|
| 认证用户 | 300 |
| 未认证用户 | 100 |
每分钟超出自动补全速率限制的请求会返回以下错误:
此端点已被请求太多次。请稍后重试。流水线创建速率限制
此设置限制流水线创建端点的请求速率。
了解更多关于 流水线创建速率限制。
Gitaly 并发限制
克隆流量会给你的 Gitaly 服务带来较大压力。为防止此类工作负载压垮 Gitaly 服务器,你可以在 Gitaly 配置文件中设置并发限制。
了解更多关于 Gitaly 并发限制。
- 默认速率限制:禁用。
问题、合并请求或提交的评论数量上限
问题、合并请求或提交可提交的评论数量存在限制。当达到限制时,系统备注仍可添加(以保留事件历史),但用户提交的评论会失败。
- 最大限制:5,000 条评论。
问题、合并请求和史诗的评论及描述大小限制
问题、合并请求和史诗的评论及描述大小存在限制。尝试添加超过限制大小的文本会导致错误,且项目也不会被创建。
未来此限制可能会调整为更低的数值。
- 最大大小:约 100 万字符 / 约 1 MB。
提交标题和描述的大小限制
可将任意大消息的提交推送到 GitLab,但以下显示限制适用:
- 标题:提交消息的第一行。限制为 1 KiB。
- 描述:提交消息的其余部分。限制为 1 MiB。
推送提交时,GitLab 会处理标题和描述,将问题(#123)和合并请求(!123)的引用替换为对应问题和合并请求的链接。
当推送包含大量提交的分支时,仅处理最后 100 次提交。
里程碑概览页面的问题数量
里程碑概览页面加载的最大问题数量为 500。当数量超过限制时,页面会显示警告并链接到分页的 问题列表,列出里程碑内的所有问题。
- 限制:500 个问题。
每次Git推送的流水线数量
当通过一次Git推送提交多个更改时(例如多个标签或分支),默认情况下仅能触发四个标签或分支流水线。此限制可防止在使用 git push --all 或 git push --mirror 时意外创建大量流水线。
合并请求流水线 也受限制。若Git推送同时更新多个合并请求,在达到限制前,每个更新的合并请求均可触发一个合并请求流水线。
GitLab自托管实例与GitLab.com的默认值为 4。
要更改GitLab自托管实例上的此限制,请使用管理区域。
增加此限制不推荐。若大量更改同时被推送,可能导致GitLab实例负载过重,甚至引发流水线洪流。
活动历史记录的保留
项目和个人的活动历史记录最多保留三年。
嵌入指标的数量
出于性能考虑,在GitLab风味Markdown(GLFM)中嵌入指标存在数量限制:
- 最大限制:100个嵌入。
HTTP响应限制
最大Gzip压缩大小
此设置用于限制解压后Gzip压缩HTTP响应的最大允许大小(以MiB为单位),以防止DoS攻击。
默认最大大小为100 MiB。若要禁用此限制,可将值设为0。若值过高,可能会使实例暴露于DoS攻击风险中。
可通过GitLab Rails控制台或使用应用设置API修改此限制:
ApplicationSetting.update(max_http_decompressed_size: 50)最大HTTP响应大小
此设置用于限制解压后的HTTP响应的最大允许大小(以MiB为单位),以防止DoS攻击。该设置适用于集成、导入器和Webhook。
默认最大大小为100 MiB。若要禁用此限制,可将值设为0。若值过高,可能会使实例暴露于DoS攻击风险中。
可通过GitLab Rails控制台或使用应用设置API修改此限制:
ApplicationSetting.update(max_http_response_size_limit: 60)Webhook限制
另见Webhook速率限制。
Webhook数量
要设置GitLab自托管实例中组或项目Webhook的最大数量,请在GitLab Rails控制台中运行以下命令:
# 若默认计划不存在限制,可先创建:
# Plan.default.create_limits!
# 项目Webhook
Plan.default.actual_limits.update!(project_hooks: 200)
# 组Webhook
Plan.default.actual_limits.update!(group_hooks: 100)将限制设为 0 可禁用此功能。
默认最大Webhook数量为每个项目 100 个、每个组 50 个。子组中的Webhook不计入其父组的Webhook限额。
对于GitLab.com,请参阅GitLab.com的Webhook限制。
Webhook有效载荷大小
最大Webhook有效载荷大小为25 MB。
Webhook超时时间
GitLab发送Webhook后等待HTTP响应的秒数。
要更改Webhook超时值:
-
在运行Sidekiq的所有GitLab节点上编辑
/etc/gitlab/gitlab.rb:gitlab_rails['webhook_timeout'] = 60 -
保存文件。
-
重新配置并重启GitLab以生效:
gitlab-ctl reconfigure gitlab-ctl restart
递归Webhook
GitLab会检测并阻止递归Webhook或超过从其他Webhook触发的Webhook数量限制的Webhook。这使得GitLab能够继续支持使用Webhook非递归调用API的工作流,或不会触发不合理数量其他Webhook的场景。
递归情况可能发生在Webhook被配置为调用自身GitLab实例(例如API)时,该调用随后触发同一Webhook并形成无限循环。
由一系列触发其他Webhook的Webhook向实例发出的最大请求数为100。当达到限制时,GitLab会阻止该系列进一步触发的任何Webhook。
被阻止的递归Webhook调用会在 auth.log 中记录消息 "Recursive webhook blocked from executing"。
导入占位符用户的限制
在导入过程中创建的占位符用户数量可以按顶级命名空间进行限制。
GitLab 自托管版本的默认限制是 0(无限制)。
若要更改 GitLab 自托管实例的这个限制,请在 GitLab Rails 控制台 中执行以下命令:
# 如果默认计划的限制不存在,你可以通过以下方式创建:
# Plan.default.create_limits!
Plan.default.actual_limits.update!(import_placeholder_user_limit_tier_1: 200)将限制设置为 0 可禁用它。
拉取镜像间隔
两次拉取刷新之间的最小等待时间 默认为 300 秒(5 分钟)。例如,在一个给定的 300 秒周期内,无论触发多少次,拉取刷新只会运行一次。
此设置适用于使用 项目 API 触发的拉取刷新,或在 设置 > 仓库 > 镜像仓库 中选择 立即更新( )强制更新的场景。该设置对 Sidekiq 用于 拉取镜像 的自动 30 分钟间隔调度无效。
若要更改 GitLab 自托管实例的这个限制,请在 GitLab Rails 控制台 中执行以下命令:
# 如果默认计划的限制不存在,你可以通过以下方式创建:
# Plan.default.create_limits!
Plan.default.actual_limits.update!(pull_mirror_interval_seconds: 200)来自自动回复器的传入邮件
GitLab 会通过查找 X-Autoreply 头部来忽略所有来自自动回复器的传入邮件。此类邮件不会在问题或合并请求中创建评论。
通过错误跟踪从 Sentry 发送的数据量
发送到 GitLab 的 Sentry 载荷有 1 MB 的最大限制,既出于安全考虑,也为了限制内存消耗。
REST API 中基于偏移的分页允许的最大偏移量
在使用基于偏移的分页时,结果集中请求的最大偏移量存在限制。此限制仅应用于同时支持键集分页的端点。有关分页选项的更多信息,请参阅 API 文档的分页部分。
若要设置 GitLab 自托管实例的这个限制,请在 GitLab Rails 控制台 中执行以下命令:
# 如果默认计划的限制不存在,你可以通过以下方式创建:
# Plan.default.create_limits!
Plan.default.actual_limits.update!(offset_pagination_limit: 10000)- 默认偏移分页限制:
50000。
将限制设置为 0 可禁用它。
CI/CD 限制
活动管道中的作业数量
每个项目的活动管道中的作业总数可被限制。每次创建新管道时都会检查此限制。活动管道指处于以下任一状态的管道:
createdpendingrunning
如果新管道会导致作业总数超过限制,则管道会因 job_activity_limit_exceeded 错误而失败。
- 在 GitLab.com 上,每个订阅层级的限制已 定义,且该限制会影响具有该层级的所有项目。
- 在 GitLab 自托管版本中,Premium 或 Ultimate 订阅下,此限制在影响所有项目的
default计划中定义。该限制默认禁用(0)。
若要设置 GitLab 自托管实例的这个限制,请在 GitLab Rails 控制台 中执行以下命令:
# 如果默认计划的限制不存在,你可以通过以下方式创建:
# Plan.default.create_limits!
Plan.default.actual_limits.update!(ci_active_jobs: 500)将限制设置为 0 可禁用它。
作业可运行的最长时间
作业可运行的最长时间默认为60分钟。运行时间超过60分钟的作业会超时。
你可以更改作业在超时前可运行的最长时间:
无论配置的超时限制如何,GitLab都会终止任何已闲置60分钟的作业。闲置作业是指未产生新日志或跟踪更新的作业。
管道中作业的最大数量
你可以限制管道中作业的最大数量。管道中的作业数量在管道创建时和新提交状态创建时进行检查。包含过多作业的管道会因size_limit_exceeded错误而失败。
- 在GitLab.com上,每个订阅层级的限制是定义好的,该限制会影响具有该层级的所有项目。
- 在GitLab Self-Managed中,Premium或Ultimate订阅,此限制在影响所有项目的
default计划下定义。默认情况下,此限制处于禁用状态(0)。
要更改GitLab Self-Managed实例的限制,请使用以下GitLab Rails控制台命令更改default计划的限制:
# 如果default计划没有限制,可以创建一个:
# Plan.default.create_limits!
Plan.default.actual_limits.update!(ci_pipeline_size: 500)将限制设置为0以禁用它。
管道中部署作业的最大数量
你可以限制管道中部署作业的最大数量。部署是指指定了environment的任何作业。管道中的部署数量在管道创建时进行检查。包含过多部署的管道会因deployments_limit_exceeded错误而失败。
对于所有GitLab Self-Managed和GitLab.com订阅,默认限制为500。
要更改GitLab Self-Managed实例的限制,请使用以下GitLab Rails控制台命令更改default计划的限制:
# 如果default计划没有限制,可以创建一个:
# Plan.default.create_limits!
Plan.default.actual_limits.update!(ci_pipeline_deployments: 500)将限制设置为0以禁用它。
限制管道层级结构大小
默认情况下,管道层级结构最多可包含1000个下游管道。当超出此限制时,管道创建会因错误downstream pipeline tree is too large而失败。
不建议增加此限制。默认限制可保护你的GitLab实例免受过度资源消耗、潜在的管道递归和数据库过载的影响。
与其增加限制,不如通过将大型管道层级结构拆分为更小的管道来重构CI/CD配置。考虑在同一管道中使用needs在作业之间或依赖阶段之间建立关系。
要在你的实例上修改此限制,请在管理区域中使用GitLab UI或在计划限制API中进行操作。
你也可以在GitLab Rails控制台中运行以下命令:
Plan.default.actual_limits.update!(pipeline_hierarchy_size: 500)此限制在GitLab.com上启用且无法更改。
项目中CI/CD订阅的数量
可以按项目限制订阅的总数。每次创建新订阅时都会检查此限制。
如果新订阅会导致订阅总数超过限制,则该订阅被视为无效。
- 在GitLab.com上,每个订阅层级的限制是定义好的,该限制会影响具有该层级的所有项目。
- 在GitLab Self-Managed的Premium或Ultimate中,此限制在影响所有项目的
default计划下定义。默认情况下,订阅限制为2。
要为GitLab Self-Managed实例设置此限制,请在GitLab Rails控制台中运行以下命令:
Plan.default.actual_limits.update!(ci_project_subscriptions: 500)将限制设置为0以禁用它。
限制流水线触发器的数量
您可以设置每个项目的流水线触发器最大数量限制。每次创建新触发器时都会检查此限制。
如果新的触发器会导致流水线触发器总数超过限制,则该触发器被视为无效。
将限制设置为 0 以禁用它。在 GitLab 自托管版中默认为 25000。
要在 GitLab 自托管实例上将此限制设置为 100,请在 GitLab Rails 控制台 中运行以下命令:
Plan.default.actual_limits.update!(pipeline_triggers: 100)此限制在 GitLab.com 上启用。
流水线计划的数量
可以按项目限制流水线计划的总数。每次创建新的流水线计划时都会检查此限制。如果新的流水线计划会导致流水线计划总数超过限制,则不会创建该流水线计划。
在 GitLab.com 上,限制是 针对每个订阅层级定义的,并且此限制会影响具有该层级的所有项目。
在 GitLab 自托管版 Premium 或 Ultimate 上,此限制是在影响所有项目的 default 计划下定义的。默认情况下,有 10 个流水线计划的限制。
要为 GitLab 自托管实例设置此限制,请在 GitLab Rails 控制台 中运行以下命令:
Plan.default.actual_limits.update!(ci_pipeline_schedules: 100)限制流水线计划每天触发的流水线数量
您可以限制流水线计划每天可以触发的流水线数量。
尝试比限制更频繁运行的计划会被减慢到最大频率。 频率是通过将 1440(一天中的分钟数)除以限制值来计算的。例如,对于最大频率:
- 每分钟一次,限制必须为
1440。\n- 每 10 分钟一次,限制必须为144。\n- 每 60 分钟一次,限制必须为24\n\n最小值为24,即每 60 分钟一个流水线。\n没有最大值。\n\n要在 GitLab 自托管实例上将此限制设置为1440,请在 GitLab Rails 控制台 中运行以下命令:
Plan.default.actual_limits.update!(ci_daily_pipeline_schedule_triggers: 1440)此限制在 GitLab.com 上启用。
限制安全策略项目中定义的计划规则数量
您可以限制每个安全策略项目中的计划规则总数。每次更新带有计划策略的策略时都会检查此限制。如果新的计划规则会导致计划规则总数超过限制,则不会处理该新计划规则。
默认情况下,GitLab 自托管版不限制可处理的计划规则数量。
要为 GitLab 自托管实例设置此限制,请在 GitLab Rails 控制台 中运行以下命令:
Plan.default.actual_limits.update!(security_policy_scan_execution_schedules: 100)此限制在 GitLab.com 上启用。
CI/CD 变量限制
可以在项目、组和实例设置中定义的 CI/CD 变量 数量都受限于整个实例。每次创建新变量时都会检查这些限制。如果新变量会导致变量总数超过相应限制,则不会创建该新变量。
要在 GitLab 自托管实例上更新其中一个限制的 default 计划,请在 GitLab Rails 控制台 中运行以下命令:
-
实例级 CI/CD 变量 限制(默认:
25):Plan.default.actual_limits.update!(ci_instance_level_variables: 30) -
每个 组级 CI/CD 变量 的限制(默认:
30000):Plan.default.actual_limits.update!(group_ci_variables: 40000) -
每个 项目级 CI/CD 变量 的限制(默认:
8000):Plan.default.actual_limits.update!(project_ci_variables: 10000)
每种制品类型的最大文件大小
由 runner 上传的使用 artifacts:reports 定义的作业制品,若文件大小超过最大文件大小限制,将被拒绝。该限制通过比较项目的最大制品大小设置与给定制品类型的实例限制来确定,并选择较小的值。
限制以兆字节为单位设置,因此可定义的最小值为 1 MB。
每种制品类型都有可设置的尺寸限制。默认值 0 表示对该特定制品类型没有限制,将使用项目的最大制品大小设置:
| 制品限制名称 | 默认值 |
|---|---|
ci_max_artifact_size_accessibility |
0 |
ci_max_artifact_size_annotations |
0 |
ci_max_artifact_size_api_fuzzing |
0 |
ci_max_artifact_size_archive |
0 |
ci_max_artifact_size_browser_performance |
0 |
ci_max_artifact_size_cluster_applications |
0 |
ci_max_artifact_size_cobertura |
0 |
ci_max_artifact_size_codequality |
0 |
ci_max_artifact_size_container_scanning |
0 |
ci_max_artifact_size_coverage_fuzzing |
0 |
ci_max_artifact_size_dast |
0 |
ci_max_artifact_size_dependency_scanning |
0 |
ci_max_artifact_size_dotenv |
0 |
ci_max_artifact_size_jacoco |
0 |
ci_max_artifact_size_junit |
0 |
ci_max_artifact_size_license_management |
0 |
ci_max_artifact_size_license_scanning |
0 |
ci_max_artifact_size_load_performance |
0 |
ci_max_artifact_size_lsif |
200 MB |
ci_max_artifact_size_metadata |
0 |
ci_max_artifact_size_metrics_referee |
0 |
ci_max_artifact_size_metrics |
0 |
ci_max_artifact_size_network_referee |
0 |
ci_max_artifact_size_performance |
0 |
ci_max_artifact_size_requirements |
0 |
ci_max_artifact_size_requirements_v2 |
0 |
ci_max_artifact_size_sast |
0 |
ci_max_artifact_size_secret_detection |
0 |
ci_max_artifact_size_terraform |
5 MB |
ci_max_artifact_size_trace |
0 |
ci_max_artifact_size_cyclonedx |
5 MB |
例如,要在 GitLab 自托管版上设置 ci_max_artifact_size_junit 限制为 10 MB,请在 GitLab Rails 控制台 中运行以下命令:
Plan.default.actual_limits.update!(ci_max_artifact_size_junit: 10)每个 GitLab Pages 网站的文件数量
每个 GitLab Pages 网站的文件条目(包括目录和符号链接)总数限制为 200,000 个。
这是 GitLab 自托管版和 GitLab.com 的默认限制。
要更新 GitLab 自托管实例中的限制,请使用 GitLab Rails 控制台。例如,要将限制更改为 100:
Plan.default.actual_limits.update!(pages_file_entries: 100)每个 GitLab Pages 网站的自定义域名数量
每个 GitLab Pages 网站的自定义域名总数限制为 150 个(适用于 GitLab.com)。
GitLab 自托管版 的默认限制为 0(无限制)。要在您的实例上设置限制,请使用 管理区。
并行 Pages 部署的数量
当使用 并行 Pages 部署 时,顶级命名空间允许的并行 Pages 部署总数为 1000 个。
每个作用域下的注册Runner数量
组和项目下注册的Runner总数有限制。每次新Runner注册时,GitLab会将这些限制与过去7天内创建或活跃的Runner进行对比。如果Runner超过了由其注册令牌确定的作用域的限制,则注册失败。如果限制值设为零,则该限制被禁用。
GitLab.com的订阅者每份订阅有不同的限制,影响使用该订阅的所有项目。
GitLab Self-Managed上的Premium和Ultimate限制由一个默认计划定义,该计划影响所有项目:
| Runner作用域 | 默认值 |
|---|---|
ci_registered_group_runners |
1000 |
ci_registered_project_runners |
1000 |
要更新这些限制,请在 GitLab Rails控制台 中运行以下命令:
# 根据所需的作用域使用ci_registered_group_runners或ci_registered_project_runners
Plan.default.actual_limits.update!(ci_registered_project_runners: 100)作业日志的最大文件大小
GitLab中作业日志文件大小的默认限制是100兆字节。任何超过此限制的作业都会被标记为失败,并被Runner丢弃。
您可以在 GitLab Rails控制台 中更改此限制。以兆字节为单位,用新值更新ci_jobs_trace_size_limit:
Plan.default.actual_limits.update!(ci_jobs_trace_size_limit: 125)GitLab Runner还有一个output_limit设置,用于配置Runner中的最大日志大小。超过Runner限制的作业会继续运行,但当达到限制时日志会被截断。
每个项目的活动DAST配置文件计划最大数量
限制每个项目中活动DAST配置文件计划的数量。DAST配置文件计划可以是活动的或不活动的。
您可以在 GitLab Rails控制台 中更改此限制。用新值更新dast_profile_schedules:
Plan.default.actual_limits.update!(dast_profile_schedules: 50)CI制品归档的最大大小
此设置用于限制动态子流水线的YAML大小。
CI制品归档的默认最大大小是5兆字节。
您可以使用 GitLab Rails控制台 更改此限制。要更新CI制品归档的最大大小,请用新值更新max_artifacts_content_include_size。例如,将其设置为20 MB:
ApplicationSetting.update(max_artifacts_content_include_size: 20.megabytes)CI/CD配置YAML文件的最大大小和深度
单个CI/CD配置YAML文件的默认最大大小是2兆字节,默认深度是100。
您可以在 GitLab Rails控制台 中更改这些限制:
-
要更新最大YAML大小,以兆字节为单位用新值更新
max_yaml_size_bytes:ApplicationSetting.update(max_yaml_size_bytes: 4.megabytes)max_yaml_size_bytes的值并非直接与YAML文件的大小相关,而是与分配给相关对象的内存有关。 -
要更新最大YAML深度,以行数为单位用新值更新
max_yaml_depth:ApplicationSetting.update(max_yaml_depth: 125)
整个CI/CD配置的最大大小
可以为完整的流水线配置(包含所有YAML配置文件)分配的最大内存量(以字节为单位)。
默认值通过将max_yaml_size_bytes(默认2 MB)与ci_max_includes(默认150)相乘计算得出:
- 在GitLab 17.2及更早版本:1 MB × 150 =
157286400字节(150 MB)。 - 在GitLab 17.3及更高版本:2 MB × 150 =
314572800字节(314.6 MB)。
你可以使用GitLab Rails控制台修改此限制。要更新CI/CD配置可分配的最大内存,请使用新值更新ci_max_total_yaml_size_bytes。例如,将其设置为20 MB:
ApplicationSetting.update(ci_max_total_yaml_size_bytes: 20.megabytes)限制dotenv变量数量
你可以设置dotenv工件中允许的最大变量数量。每次导出dotenv文件作为工件时都会检查此限制。
将限制设置为0可禁用它。在GitLab自托管版上默认值为20。
要在你的实例上将此限制设置为100,请在GitLab Rails控制台中运行以下命令:
Plan.default.actual_limits.update!(dotenv_variables: 100)此限制在GitLab.com上启用。
限制dotenv文件大小
你可以设置dotenv工件的最大大小。每次导出dotenv文件作为工件时都会检查此限制。
将限制设置为0可禁用它。默认值为5 KB。
要在GitLab自托管版实例上将此限制设置为5 KB,请在GitLab Rails控制台中运行以下命令:
Plan.default.actual_limits.update!(dotenv_size: 5.kilobytes)限制CI/CD作业注释数量
你可以设置每个CI/CD作业中注释的最大数量。
将限制设置为0可禁用它。在GitLab自托管版上默认值为20。
要在你的实例上将此限制设置为100,请在GitLab Rails控制台中运行以下命令:
Plan.default.actual_limits.update!(ci_job_annotations_num: 100)限制CI/CD作业注释文件大小
你可以设置CI/CD作业注释的最大大小。
将限制设置为0可禁用它。默认值为80 KB。
要在GitLab自托管版实例上将此限制设置为100 KB,请在GitLab Rails控制台中运行以下命令:
Plan.default.actual_limits.update!(ci_job_annotations_size: 100.kilobytes)CI/CD表的数据库分区最大大小
分区表的分区在使用前可用的最大磁盘空间(以字节为单位),超过后自动创建新分区。默认值为100 GB。
你可以使用GitLab Rails控制台修改此限制。要更改限制,请使用新值更新ci_partitions_size_limit。例如,将其设置为20 GB:
ApplicationSetting.update(ci_partitions_size_limit: 20.gigabytes)自动流水线清理的最大配置值
配置 CI/CD 流水线过期时间 的上限。默认值为 1 年。
你可以通过 GitLab Rails 控制台 更改此限制。要更改限制,请使用新值更新 ci_delete_pipelines_in_seconds_limit_human_readable。例如,将其设置为 3 年:
ApplicationSetting.update(ci_delete_pipelines_in_seconds_limit_human_readable: '3 years')实例监控与指标
限制入站事件管理警报数量
此设置会限制一段时间内入站警报负载的数量。
有关更多信息,请参阅 事件管理速率限制。
Prometheus 警报 JSON 负载
发送到 notify.json 端点的 Prometheus 警报负载大小限制为 1 MB。
通用警报 JSON 负载
发送到 notify.json 端点的警报负载大小限制为 1 MB。
环境仪表板限制
- 层级:Premium, Ultimate
- 提供方:GitLab.com, GitLab 自托管, GitLab 专用
有关显示项目的最大数量,请参阅 环境仪表板。
部署板上的环境数据
部署板 会从 Kubernetes 加载关于 Pod 和 Deployment 的信息。但是,从 Kubernetes 读取的某个环境数据超过 10 MB 时,将不会显示这些数据。
合并请求
差异限制
GitLab 对以下方面有限制:
- 单个文件的补丁大小。可在 GitLab 自托管版中配置。
- 合并请求所有差异的总大小。
对上述每一项均适用上下限:
- 变更文件的数量。
- 变更行的数量。
- 显示变更的累积大小。
下限会导致额外的差异被折叠。上限则阻止更多变更被渲染。有关这些限制的详细信息,请阅读 GitLab 开发文档中关于处理差异的内容。
差异版本限制
此功能的可用性受功能标志控制。有关更多信息,请参阅历史记录。该功能可用于测试,但不适用于生产环境。
GitLab 将每个合并请求的限制设为 1000 个 差异版本。达到此限制的合并请求无法进一步更新。相反,应关闭受影响的合并请求并创建新的合并请求。
合并请求报告大小限制
超过 20 MB 限制的报告不会被加载。受影响的报告包括:
高级搜索限制
最大索引文件大小
你可以为存储库文件在 Elasticsearch 中建立索引的内容设置限制。任何大于此限制的文件仅索引文件名。文件内容既不被索引也不可搜索。
设置限制有助于减少索引过程的内存使用量和总体索引大小。此值默认为 1024 KiB(1 MiB),因为任何文本文件超过此大小可能并非人类可读。
你必须设置限制,因为不支持无限制的文件大小。将此值设置为大于 GitLab Sidekiq 节点内存量会导致 GitLab Sidekiq 节点因索引期间预分配了这么多内存而耗尽内存。
最大字段长度
你可以为高级搜索中索引的文本字段内容设置限制。
设置最大值有助于减少索引过程的负载。如果任何文本字段超过此限制,则文本会被截断到指定字符数。其余文本不会被索引,也无法搜索。
这适用于所有已索引的数据,但仓库文件除外——它们有单独的限制。更多信息请阅读 Maximum file size indexed。
- 在 GitLab.com 上,字段长度限制为 20,000 个字符。
- 对于 GitLab 自托管实例,字段长度默认无限制。
你可以在启用 Elasticsearch 时为 GitLab 自托管实例配置此限制。将限制设置为 0 以禁用它。
数学渲染限制
GitLab 在渲染 Markdown 字段中的数学公式时施加默认限制。这些限制提供更好的安全性和性能。
针对问题、合并请求、史诗、维基和仓库文件的限制:
- 最大宏展开次数:
1000。 - 用户指定的 em 大小上限:
20。 - 渲染节点数量上限:
50。 - 数学块中的字符数上限:
1000。 - 渲染时间上限:
2000 毫秒。
当你运行 GitLab 自托管且信任用户输入时,可以禁用这些限制。
使用 GitLab Rails 控制台:
ApplicationSetting.update(math_rendering_limits_enabled: false)也可以使用 GraphQL 或 REST API 按组禁用这些限制。
如果禁用了限制,问题、合并请求、史诗、维基和仓库文件中的数学公式渲染几乎不受限。这意味着恶意行为者可能添加会导致浏览器查看时出现 DoS 的数学公式。你必须确保只有你信任的人才能添加内容。
维基限制
片段限制
参见 关于片段设置的文档。
设计管理限制
参见 向问题添加设计 部分的限制。
推送事件限制
最大推送大小
允许的最大 推送大小。
GitLab 自托管实例默认未设置。对于 GitLab.com,请参阅 账户与限制设置。
Webhook 和项目服务
单次推送中分支或标签的总变更数。若变更数超过指定限制,Hook 将不会执行。
更多信息请见:
活动
单次推送中分支或标签的总变更数,用于确定创建单个推送事件还是批量推送事件。
更多信息请见 推送事件活动限制与批量推送事件文档。
包注册表限制
文件大小限制
上传到 GitLab 包注册表 的包的默认最大文件大小因格式而异:
- Conan:3 GB
- 通用:5 GB
- Helm:5 MB
- Maven:3 GB
- npm:500 MB
- NuGet:500 MB
- PyPI:3 GB
- Terraform:1 GB
GitLab.com 上的最大文件大小 可能不同。
要为 GitLab 自托管实例设置这些限制,可通过 Admin 区域 操作,或在 GitLab Rails 控制台 中运行以下命令:
# 文件大小限制以字节为单位存储
# 针对 Conan 包
Plan.default.actual_limits.update!(conan_max_file_size: 100.megabytes)
# 针对 npm 包
Plan.default.actual_limits.update!(npm_max_file_size: 100.megabytes)
# 针对 NuGet 包
Plan.default.actual_limits.update!(nuget_max_file_size: 100.megabytes)# 对于 Maven 包
Plan.default.actual_limits.update!(maven_max_file_size: 100.megabytes)
# 对于 PyPI 包
Plan.default.actual_limits.update!(pypi_max_file_size: 100.megabytes)
# 对于 Debian 包
Plan.default.actual_limits.update!(debian_max_file_size: 100.megabytes)
# 对于 Helm 图表
Plan.default.actual_limits.update!(helm_max_file_size: 100.megabytes)
# 对于通用包
Plan.default.actual_limits.update!(generic_packages_max_file_size: 100.megabytes)将限制设置为 0 以允许任意文件大小。
返回的包版本数
当请求给定 NuGet 包名称的版本时,GitLab 包注册表最多返回 300 个版本。
依赖代理限制
缓存到 依赖代理 中的镜像的最大文件大小因文件类型而异:
- 镜像 blob:5 GB
- 镜像清单:10 MB
分配者和审阅者的最大数量
问题和合并请求会执行这些最大值:
- 最大分配者:200
- 最大审阅者:200
基于 CDN 的 GitLab.com 限制
除应用级限制外,GitLab.com 配置使用 Cloudflare 标准的 DDoS 防护和 Spectrum 保护 Git over SSH。Cloudflare 终止客户端 TLS 连接,但不具备应用感知能力,无法用于与用户或组绑定的限制。Cloudflare 页面规则和速率限制通过 Terraform 配置。这些配置不公开,因为它们包含检测恶意活动的安全和滥用实现,公开会导致这些操作失效。
容器仓库标签删除限制
容器仓库中的标签位于容器注册表中,因此每个标签删除都会触发对容器注册表的网路请求。由于这一点,我们限制了单个 API 调用可以删除的标签数量为 20 个。
项目级安全文件 API 限制
安全文件 API 执行以下限制:
- 文件必须小于 5 MB。
- 项目不能拥有超过 100 个安全文件。
变更日志 API 限制
变更日志 API 执行以下限制:
from和to之间的提交范围不得超过 15000 个提交。
价值流分析限制
- 每个命名空间(例如组或项目)最多可以有 50 个价值流。
- 每个价值流最多可以有 15 个阶段。
审计事件流式传输目标限制
自定义 HTTP 端点
- 每个顶级组最多可以有 5 个自定义 HTTP 流式传输目标。
Google Cloud Logging
- 每个顶级组最多可以有 5 个 Google Cloud Logging 流式传输目标。
Amazon S3
- 每个顶级组最多可以有 5 个 Amazon S3 流式传输目标。
## 列出所有实例限制
若要列出所有实例限制值,请在 [GitLab Rails 控制台](operations/rails_console.md#starting-a-rails-console-session) 中运行以下命令:
```ruby
Plan.default.actual_limits示例输出:
id: 1,
plan_id: 1,
ci_pipeline_size: 0,
ci_active_jobs: 0,
project_hooks: 100,
group_hooks: 50,
ci_project_subscriptions: 3,
ci_pipeline_schedules: 10,
offset_pagination_limit: 50000,
ci_instance_level_variables: "[FILTERED]",
storage_size_limit: 0,
ci_max_artifact_size_lsif: 200,
ci_max_artifact_size_archive: 0,
ci_max_artifact_size_metadata: 0,
ci_max_artifact_size_trace: "[FILTERED]",
ci_max_artifact_size_junit: 0,
ci_max_artifact_size_sast: 0,
ci_max_artifact_size_dependency_scanning: 350,
ci_max_artifact_size_container_scanning: 150,
ci_max_artifact_size_dast: 0,
ci_max_artifact_size_codequality: 0,
ci_max_artifact_size_license_management: 0,
ci_max_artifact_size_license_scanning: 100,
ci_max_artifact_size_performance: 0,
ci_max_artifact_size_metrics: 0,
ci_max_artifact_size_metrics_referee: 0,
ci_max_artifact_size_network_referee: 0,
ci_max_artifact_size_dotenv: 0,
ci_max_artifact_size_cobertura: 0,
ci_max_artifact_size_terraform: 5,
ci_max_artifact_size_accessibility: 0,
ci_max_artifact_size_cluster_applications: 0,
ci_max_artifact_size_secret_detection: "[FILTERED]",
ci_max_artifact_size_requirements: 0,
ci_max_artifact_size_coverage_fuzzing: 0,
ci_max_artifact_size_browser_performance: 0,
ci_max_artifact_size_load_performance: 0,
ci_needs_size_limit: 2,
conan_max_file_size: 3221225472,
maven_max_file_size: 3221225472,
npm_max_file_size: 524288000,
nuget_max_file_size: 524288000,
pypi_max_file_size: 3221225472,
generic_packages_max_file_size: 5368709120,
golang_max_file_size: 104857600,
debian_max_file_size: 3221225472,
project_feature_flags: 200,
ci_max_artifact_size_api_fuzzing: 0,
ci_pipeline_deployments: 500,
pull_mirror_interval_seconds: 300,
daily_invites: 0,
rubygems_max_file_size: 3221225472,
terraform_module_max_file_size: 1073741824,
helm_max_file_size: 5242880,
ci_registered_group_runners: 1000,
ci_registered_project_runners: 1000,
ci_daily_pipeline_schedule_triggers: 0,
ci_max_artifact_size_cluster_image_scanning: 0,
ci_jobs_trace_size_limit: "[FILTERED]",
pages_file_entries: 200000,
dast_profile_schedules: 1,
external_audit_event_destinations: 5,
dotenv_variables: "[FILTERED]",
dotenv_size: 5120,
pipeline_triggers: 25000,
project_ci_secure_files: 100,
repository_size: 0,
security_policy_scan_execution_schedules: 0,
web_hook_calls_mid: 0,
web_hook_calls_low: 0,
project_ci_variables: "[FILTERED]",
group_ci_variables: "[FILTERED]",
ci_max_artifact_size_cyclonedx: 1,
rpm_max_file_size: 5368709120,
pipeline_hierarchy_size: 1000,
ci_max_artifact_size_requirements_v2: 0,
enforcement_limit: 0,
notification_limit: 0,
dashboard_limit_enabled_at: nil,
web_hook_calls: 0,
project_access_token_limit: 0,
google_cloud_logging_configurations: 5,
ml_model_max_file_size: 10737418240,
limits_history: {},
audit_events_amazon_s3_configurations: 5列表中某些限制值显示为 [FILTERED] 是因为 Rails 控制台中的过滤。