多次修改后的SVN性能答案

【问题标题】：SVN performance after many revisions多次修改后的SVN性能
【发布时间】：2008-09-24 15:00:32
【问题描述】：

我的项目目前正在使用一个 svn 存储库，它每天会获得数百个新修订。存储库位于 Win2k3 服务器上，并通过 Apache/mod_dav_svn 提供服务。

我现在担心随着时间的推移，性能会因修订过多而下降。
这种恐惧合理吗？
我们已经计划升级到 1.5，因此从长远来看，在一个目录中拥有数千个文件不会成为问题。

Subversion 存储 2 个修订版之间的 delta（差异），因此这有助于节省大量空间，特别是在您只提交代码（文本）而没有二进制文件（图像和文档）的情况下。

这是否意味着为了检查文件 foo.baz 的修订版 10，svn 将采用修订版 1，然后应用 deltas 2-10？

【问题讨论】：

标签： performance svn repository fsfs

【解决方案1】：

你有什么类型的回购？ FSFS 还是 BDB？

（我们现在假设 FSFS，因为这是默认设置。）

在 FSFS 的情况下，每个修订都存储为与前一个的差异。所以，你会认为是的，经过多次修改，它会很慢。

但是，事实并非如此。 FSFS 使用所谓的“跳过增量”来避免对以前的版本进行过多的查找。

（因此，如果您使用的是 FSFS 存储库，Brad Wilson 的回答是错误的。）

在 BDB 存储库的情况下，HEAD（最新）修订版是全文，但较早的修订版构建为一系列针对 head 的差异。这意味着每次提交后必须重新计算之前的转速。

附：我们的 repo 大约 20GB，大约有 35,000 次修订，我们没有注意到任何性能下降。

【讨论】：

在你 20GB 的 repo 中，是存储为 FSFS 还是 BDB？
这是 FSFS（至少现在是这样）。在我们的 repo 生命周期的第一年左右，它是 BDB（FSFS 还不存在）。在某些时候，我们进行了转储/加载循环以转换为 FSFS。 BDB 没有任何具体问题，但 FSFS 在架构上似乎更好（因此 FSFS 现在是默认设置）。
这是一条有趣的信息。我有一个包含 73000 个文件（大约 350 MB）的存储库，而且速度慢得令人难以置信。我得问问他们在用什么。
附带说明，PHP 存储库存储在 Subversion 上，（在撰写本文时）有 295,197 个修订版。 svn.php.net/repository/php/php-src/trunk

【解决方案2】：

Subversion 将最新版本存储为全文，并带有向后看的差异。这意味着对 head 的更新总是很快，而您逐步支付的费用是回顾历史。

【讨论】：

Subversion 使用前瞻性增量。
根据这里的答案，你说得对：“Subversion 在 FSFS 存储库中使用前向增量，在 BDB 存储库中使用后向增量”stackoverflow.com/questions/8824597/…

【解决方案3】：

对于实际项目，我个人没有处理过代码库大于 80K LOC 的 Subversion 存储库。我实际拥有的最大存储库大约是 1.2 gig，但这包括项目使用的所有库和实用程序。

我认为日常使用不会受到太大影响，但是需要查看不同版本的任何内容都可能会减慢一点速度。它甚至可能不明显。

现在，从系统管理员的角度来看，有一些事情可以帮助您最大限度地减少性能瓶颈。由于 Subversion 主要是基于文件的系统，您可以这样做：

将实际存储库放在不同的驱动器中
确保除了 svn 之外没有文件锁定应用在上面的驱动器上运行
使驱动器的转速至少为 7,500 RPM。您可以尝试获得 10,000 RPM，但这可能是矫枉过正
如果每个人都在同一个办公室，请将 LAN 更新为千兆。

这对于您的情况可能有点过头了，但这是我通常对其他文件密集型应用程序所做的事情。

如果您曾经“超越” Subversion，那么Perforce 将是您的下一步。它是超大型项目最快的源代码控制应用程序。

【讨论】：

【解决方案4】：

我们正在运行一个包含数千兆字节代码和二进制文件的颠覆服务器，它的修订版本多达两万多个。还没有减速。

【讨论】：

【解决方案5】：

Subversion 仅存储 2 个修订版之间的 delta（差异），因此这有助于节省大量空间，特别是在您仅提交代码（文本）而没有二进制文件（图像和文档）的情况下。

此外，我见过很多非常大的项目使用 svn，并且从未抱怨过性能。

也许您担心结帐时间？那么我想这确实是一个网络问题。

哦，我在 CVS 存储库上工作过 2Gb+ 的东西（代码、imgs、文档），从来没有遇到过性能问题。由于 svn 对 cvs 有很大的改进，我认为您不必担心。

希望它可以帮助你放松一点;）

【讨论】：

【解决方案6】：

我不认为我们的颠覆会因老化而减慢。我们目前有几个 TeraBytes 的数据，大部分是二进制的。我们每天签出/提交最多 50 GB 的数据。我们目前总共有 50000 次修订。我们使用 FSFS 作为存储类型，并直接连接 SVN：（Windows 服务器）或通过 Apache mod_dav_svn（Gentoo Linux 服务器）。

我无法确认这会使 svn 随着时间的推移而变慢，因为我们设置了一个干净的服务器来进行性能比较，我们可以与之进行比较。我们无法测量出显着的下降。

但是我不得不说，默认情况下我们的 subversion 非常慢，显然它是 subversion 本身，因为我们尝试使用另一个计算机系统。

由于某些未知原因，subversion 似乎完全受服务器 CPU 限制。我们的结帐/提交率限制在每个客户端 15-30 兆字节/秒之间，因为这样一个服务器 CPU 内核就会完全用完。这对于一个几乎空的存储库（1 GigaByte，5 个修订版）和我们的完整服务器（~5 TeraByte，50000 个修订版）是一样的。像将压缩设置为 0 = 关闭这样的调整并没有改善这一点。

我们的高带宽（提供约 1 GigaBytes/s）FC 阵列空闲，其他内核空闲和网络（当前客户端为 1 GigaBit/s，服务器为 10 GigaBits/s）也空闲。好吧，不是真的空闲，但如果只使用了 2-3% 的可用容量，我称之为空闲。

看到所有组件都处于空闲状态并不是很有趣，我们需要等待我们的工作副本被检出或提交。基本上我不知道服务器进程在结帐/提交期间一直完全消耗一个 CPU 内核在做什么。

但是我只是想找到一种方法来调整颠覆。如果这不可能，我们可能需要切换到另一个系统。

因此：回答：没有 SVN 不会降低性能，它最初很慢。

当然，如果您不需要（高）性能，您不会有问题。顺便提一句。以上均适用于 subversion 1.7 最新稳定版

【讨论】：

“我们目前有几个 TeraBytes 的数据，主要是二进制数据。我们每天检查/提交多达 50 GB 的数据。我们目前总共有 50000 个修订版”。这是令人难以置信的！自从你在 2013 年写这篇文章以来，你有没有看到你提到的通过迁移到新版本的 Subversion 来改善 CPU 消耗问题（如果你迁移了；可能会迁移这么大的 repo）？

【解决方案7】：

唯一可能减慢速度的操作是从多个修订版中读取信息的操作（例如 SVN Blame）。

【讨论】：

【解决方案8】：

我不确定.....我在 Centos 5.2 上使用 SVN 和 apache。工作正常。修订号是 8230 之类的……在所有客户端计算机上，提交速度非常慢，以至于我们必须等待至少 2 分钟才能获得 1kb 的文件。我说的是 1 个没有大文件大小的文件。

然后我创建了一个新的存储库。从转速开始。 1. 现在工作正常。快速地。使用 svnadmin 创建 xxxxxx。没有检查是FSFS还是BDB.....

【讨论】：

【解决方案9】：

也许您应该考虑改进您的工作流程。

我不知道回购在这些情况下是否会出现性能问题，但您能够回到正常的修订版。

在您的情况下，您可能希望包含一个验证过程，因此团队负责人存储库中的团队提交，并且他们每个人都提交到团队经理存储库，团队经理存储库提交到只读干净的公司存储库。你已经在它的阶段做出了一个干净的选择，什么提交必须放在顶部。

这样，任何人都可以返回到干净的副本，并且可以轻松浏览历史记录。合并更容易，开发人员仍然可以随意提交他们的烂摊子。

【讨论】：