不久之前,我发布了一个问题,要求就修复由于大量二进制文件很慢的仓库的计划提供反馈.这个问题(不是必须阅读的):修复因大二进制文件而变慢的git仓库
我遵循了我的计划,并经历了意想不到的副作用.
我们回购的新鲜克隆最初需要2-3个小时.想通了服务器开始交换,在完成git config pack.windowMemory 100m && git config pack.packSizeLimit 200m后,克隆时间下降到~15分钟.
我想我仍然会完成其余的计划,所以我为我们拥有的二进制类型禁用了delta compresson,并在repo上运行了git repack -a -d -F.
在此之后,回购的新鲜克隆需要大约20分钟,所以它实际上变得更糟.但真正的问题是每次有人已经克隆了repo尝试推送提交时,他们会"自动打包存储库以获得最佳性能".
关于可能出错的问题,以及如何/应该修复的想法？
可能是你的仓库的大小和你的低价值使得pack.packSizeLimit包的数量总是高于gc.autopacklimit。因此，增加其中任何一个以确保 gc 不会在每次提交时运行。
我不确定packSizeLimit会以何种方式影响记忆，但我不相信它会产生任何重大影响。如果您的实验表明情况并非如此，请纠正我。直接影响内存使用的参数是pack.windowMemory和pack.deltaCacheSize。