GitLab错误上报仓库大小超出限制 如何强制重新计算仓库实际存储

异常存储占用的遗漏原因 #

• 悬空对象未到清理周期：GitLab默认的housekeeping操作会保留最近2周内的悬空提交/文件对象，不会直接清理。如果历史上曾经推送过超大文件后删除分支/回滚，这些大文件对象会在GitLab服务端留存到保留周期结束，而本地clone只会拉取当前分支可达的对象，所以本地看不到这部分占用。
• 合并请求关联引用留存：GitLab会为每个未删除的合并请求创建独立的引用路径refs/merge-requests/*，就算合并请求的源分支已经被删除，只要合并请求本身没有被彻底删除，其关联的所有提交、文件对象都不会被GC回收。如果历史合并请求中曾经提交过大文件，这部分占用会一直留存，且默认不会被本地clone拉取。
• 仓库大小统计缓存异常：GitLab的仓库大小统计默认采用增量更新机制，不会每次都全量扫描计算。如果之前的大文件操作导致统计值异常累加，后续删除文件的操作如果没有触发统计缓存重置，就会一直显示错误的大小数值，甚至出现housekeeping后数值上涨的异常情况。
• 历史残留的特殊对象：如果仓库曾经开启过Git LFS后关闭、或者曾经上传过CI产物/包后删除配置，残留的LFS对象、未被清理的历史CI产物也会被计入仓库总存储，且不会被普通clone拉取。

强制GitLab重算仓库实际大小的方法 #

项目所有者权限可操作方案 #

1. 先清理冗余资源：彻底删除所有已合并/废弃的合并请求，确认没有留存不必要的历史分支、标签。
2. 触发全量仓库清理：进入项目「设置」→「仓库」→「仓库维护」→「高级设置」，选择清理所有未引用的LFS对象，再点击立即运行完整housekeeping，该操作会跳过默认的悬空对象保留周期，直接清理所有不可达的Git对象。
3. 触发统计重算：部分GitLab版本在上述页面提供重新计算仓库大小的独立选项，点击即可触发全量统计更新；如果没有该选项，完整housekeeping运行完成后会自动触发统计重算，通常等待10-30分钟即可看到更新后的数值。

自托管GitLab管理员专属操作 #

如果是私有部署的GitLab实例，可登录服务器执行命令强制清理+重算：

• 进入对应仓库的文件存储目录，执行原生Git全量GC：git gc --prune=now --aggressive
• 执行GitLab自带的大小重算任务：gitlab-rake gitlab:usage_data:recalculate_repository_size PROJECT_ID=<你的项目数字ID>

内容的提问来源于stack exchange，提问作者stephen_mxr