使用数十万个小文件提高git存储库的性能

Question

我正在尝试提高一个git存储库的性能，这个存储库几乎只被我用来对一个科学计算项目进行版本控制。该项目的模拟软件将极小(小于100KB)的纯文本文件分解到相当深的目录中，表示独立的、相对经济的模拟结果。我指出，这些是经济的，表明我可以在短时间内创建数千个它们，这意味着情况只会变得更糟。这些模拟是以批处理的形式运行的，这可能意味着单个提交可以包括数百MB的数据，所有这些数据都以这些由微小的文本文件填充的深子树的形式存在。我正在运行的机构计算集群使用33TB的盘式驱动器RAID6阵列来存储我组的所有数据(如果重要的话，这个驱动器目前没有足够的空间--大约1.6TB)。

我相当确定这是RAID6数组的糟糕性能，因为当我运行顶级git add .时，它可能需要几十分钟，即使只有几个文件发生了更改。承诺也同样糟糕。推送，一旦事情提交，通常仍然需要几分钟，但速度更快(推送的缓慢部分不是它通过网络发送数据的部分)。在我请求额外内核的交互式会话中完成所有这些操作也会加快速度，但添加新的模拟结果仍然需要几分钟的时间。当我在装有现代NVME-PCIE固态硬盘的笔记本电脑上执行同样的操作时，这些操作需要几秒钟。

那么，有什么建议吗？我查看了git lfs，但我不相信这会对我有很大帮助，因为它将创建的指针不会比它们将指向的文件小一百万倍，这是正常的用例。如果人们仍然认为这会有帮助，我想我可以试一试。另外，如果重要的话，集群的linux是旧的(当然)，所以：git version 1.8.3.1...

如果需要，很乐意添加更多的上下文。编辑git count-objects -vH退货：

count: 1
size: 4.00 KiB
in-pack: 229216
packs: 1
size-pack: 1.25 GiB
prune-packable: 0
garbage: 0
size-garbage: 0 bytes

另外，我确实添加了large-data标签，尽管我的数据可以轻松地存储在一个设备的存储介质中。我添加它是因为数据已经变得足够大/复杂，以至于变得笨拙，正如这篇文章所解释的那样。如果人们认为这真的不合适，我可以删除它。

Answer 1

正如@CodeCaster指出的那样，我的集群上的git确实很古老，这在一定程度上是问题的根源。我不完全相信我的学校集群上的raid阵列不是因为某种原因而变得很慢，但在更新到更新的git之后，我的拉、推、添加和提交都变得不那么痛苦了。它们已经从几十分钟变成了几秒钟(这是我习惯的速度)。

值得一提的是，this SO answer说服了我尝试升级git (再次感谢@CodeCaster)。正如@torek所指出的那样，repos是向后兼容的，所以我的repo在处理我的repo时没有任何问题，我的repo是从2015年开始用今年的git处理的。

如果任何阅读本文的人得出结论，因为他们在共享基础设施上没有root，所以追求这个解决方案对他们来说是恼人的，我的方法是使用conda在我使用的conda环境中安装一个不同的git。在这篇文章中，在干净的miniconda3环境中使用conda install -c conda-forge git将会得到git2.30.2，这已经是相当新的版本了。另一篇文章中提到的最新性能更新是2.24版。我认为还有其他途径可以在本地安装git，但在科学计算环境中，用户通常可以毫不费力地使用本地conda，这似乎是通向较新版本的最简单途径。