50

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

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

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

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

4

9 回答 9

60

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

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

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

然而，事实并非如此。FSFS 使用所谓的“跳过增量”来避免对以前的转速进行过多的查找。

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

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

欲了解更多信息：http: //svn.apache.org/repos/asf/subversion/trunk/notes/skip-deltas

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

于 2008-09-25T01:54:19.350 回答
15

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

于 2008-09-24T15:14:44.317 回答
5

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

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

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

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

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

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

于 2008-09-24T15:17:49.270 回答
4

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

于 2008-09-24T15:20:39.997 回答
3

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

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

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

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

希望它可以帮助您放松一下；）

于 2008-09-24T15:04:59.113 回答
3

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

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

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

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

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

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

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

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

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

于 2013-11-18T16:54:59.747 回答
2

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

于 2008-09-24T15:10:59.693 回答
-1

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

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

于 2009-04-17T18:52:30.770 回答
-2

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

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

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

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

于 2010-02-26T09:07:14.133 回答