GitLab-ce仓库Push/删分支缓慢报错，求排查解决方案

问题背景 #

CentOS服务器部署GitLab CE Omnibus 17.5.1，某活跃旧仓库包含52000次提交、190个分支，总存储850MiB，约36000个文件。当前问题：

1. 任意分支git push时，Writing objects步骤后延迟5-6分钟，加-v可见卡在POST git-receive-pack (471 bytes)阶段；
2. 执行git push origin --delete删除旧分支时，报错remote: fatal: Invalid revision range ...，耗时3-5分钟但最终成功；通过GitLab管理面板删除则因“4:Deadline Exceeded”失败。

已尝试重启GitLab、增大http.postBuffer、切换HTTPS/SSH、指定--ipv4，均无效；仓库最大文件为22MB字体文件，日志未发现有效线索。

排查步骤 #

1. 仓库垃圾回收与后台任务清理 #

• 触发仓库垃圾回收：针对单个仓库执行sudo gitlab-rake gitlab:gc:repo[namespace/my]（替换为实际仓库路径），或全量执行sudo gitlab-rake gitlab:gc:all，清理冗余Git对象与历史碎片。
• 检查阻塞的后台任务：执行sudo gitlab-rails runner "p Project.find_by_full_path('namespace/my').pending_builds.count"，确认是否有停滞的CI/CD任务或钩子进程。

2. 追踪git-receive-pack执行细节 #

• 开启Git操作Debug日志：修改/etc/gitlab/gitlab.rb，设置gitlab_rails['git_log_level'] = 'debug'，执行sudo gitlab-ctl reconfigure生效。之后重新执行异常操作，查看/var/log/gitlab/gitlab-rails/git_json.log，定位git-receive-pack阶段的具体耗时节点。
• 本地模拟推送流程：进入仓库存储路径（可通过GitLab管理面板仓库详情页获取），执行git receive-pack .，手动模拟客户端推送，观察是否有卡顿或错误输出。

3. 修复Git引用与数据库一致性 #

• 检查仓库对象完整性：执行sudo gitlab-rake gitlab:git:fsck，修复可能的引用损坏；再执行sudo gitlab-rake gitlab:housekeeping:all，清理无效分支引用与数据库冗余记录。
• 验证缺失提交哈希：针对分支删除报错中的哈希，在仓库目录执行git cat-file -p cd177661ec51829df548a3b2153e70d31bcbcc58，确认提交对象是否存在；若不存在，手动清理无效引用：git update-ref -d refs/heads/my-really-old-branch。

4. 服务器资源与GitLab配置优化 #

• 监控资源占用：在执行异常操作时，用top、iostat、vmstat实时监控CPU、内存、磁盘IO，排查是否存在IO瓶颈或内存不足导致的进程阻塞。
• 调整Git进程参数：修改/etc/gitlab/gitlab.rb，添加或调整以下配置：

  gitlab_workhorse['env'] = {
    'GIT_MAX_PACK_SIZE' => '1g',
    'GIT_PACK_WINDOW' => '1000',
    'GIT_PACK_WINDOW_MEMORY' => '512m'
  }
  

  执行sudo gitlab-ctl reconfigure后重启GitLab服务。

5. 排查自定义钩子与外部集成 #

• 临时禁用仓库钩子：进入仓库目录的hooks文件夹，将自定义脚本（如pre-receive、post-receive）重命名（例如pre-receive.bak），测试操作是否恢复正常，排除钩子脚本导致的延迟。
• 禁用外部集成：临时关闭仓库关联的Webhook、CI/CD流水线等外部服务，测试操作耗时变化，确认是否为外部响应慢导致的阻塞。

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