大Git仓库频繁执行git push导致高CPU进程挂起问题求助

核心问题分析 #

当前问题的根源在于：50GB+的大仓库中，每次单文件提交后立即执行git push，导致每个推送都要重新执行仓库差异打包（git-pack-objects），且HTTP传输方式的默认配置无法适配大仓库的推送需求，进而引发进程挂起、CPU资源浪费（单核满载但实际有效CPU时间占比低）、多进程堆积的问题。

针对性Git配置调整方案 #

以下配置直接作用于Git的打包、HTTP传输逻辑，解决你遇到的性能瓶颈：

1. 优化打包过程（解决git-pack-objects低效问题）

利用4核机器的多线程能力，增大打包缓存，减少磁盘IO等待：

# 让打包过程使用全部4核CPU
git config --global pack.threads 4
# 给打包窗口分配足够内存，减少临时磁盘写入
git config --global pack.windowMemory 1g
# 增大增量缓存，避免重复计算文件差异
git config --global pack.deltaCacheSize 512m
# 限制单个pack文件大小，避免超大文件传输阻塞
git config --global pack.packSizeLimit 2g

作用：解决你观察到的git-pack-objects运行4小时但实际CPU时间仅45分钟的问题——减少磁盘IO等待，让CPU持续高效工作，同时利用多核降低打包耗时。

2. 优化HTTP传输（解决git-remote-http高CPU/挂起问题）

调整HTTP传输的缓存、连接复用和超时逻辑：

# 增大HTTP POST缓冲区，减少分段传输次数
git config --global http.postBuffer 524288000
# 增大HTTP请求缓冲区，适配大仓库的元数据传输
git config --global http.maxRequestBuffer 100m
# 禁用低速检测，避免网络波动导致进程无意义挂起
git config --global http.lowSpeedLimit 0
git config --global http.lowSpeedTime 0
# 启用HTTP连接复用，减少进程创建销毁开销
git config --global http.keepAlive true
git config --global http.reuseConnection true

作用：降低git-remote-http因频繁处理小分段请求导致的高CPU占用，同时避免因误判低速连接而挂起的进程，复用连接减少多进程堆积。

3. 可选：启用推送压缩优化

进一步减少传输数据量：

# 启用高压缩级别（平衡压缩速度和体积）
git config --global core.compression 6
# 推送时使用压缩
git config --global push.compression true

补充脚本优化建议（配合配置效果更佳） #

不要每个文件单独执行git push——将多个git add/git commit批量执行后，每10-20次commit再统一推送一次。频繁的单次推送是大仓库性能灾难的核心诱因，即使配置优化，也无法抵消多次打包的开销。

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