logo标签列表

许多修订版本之后的SVN性能

performancesvnrepositoryfsfs
50

我的项目目前使用svn存储库，每天会新增数百个新版本。该存储库位于Win2k3服务器上，并通过Apache/mod_dav_svn提供服务。

我现在担心随着时间的推移，由于版本过多而导致性能下降。
这种担忧是否合理？
我们已经计划升级到1.5，因此长期内一个目录中有数千个文件将不会成为问题。

Subversion只存储两个版本之间的差异（delta），因此可以节省大量空间，尤其是如果您只提交代码（文本）而没有二进制文件（图像和文档）的情况下。

这是否意味着为了检出文件foo.baz的第10个版本，svn会先获取第1个版本然后再应用第2-10个版本之间的差异？

9个回答
60

你的代码库是哪种类型的？FSFS还是BDB？

（暂且假设使用的是FSFS，因为这是默认选项。）

对于FSFS来说，每个版本都存储为与前一个版本的差异。所以，你可能会认为，经过多个版本后，它会变得非常缓慢。

然而，实际并非如此。FSFS使用所谓的“跳跃增量”来避免在之前的修订中进行太多查找。

（因此，如果你正在使用FSFS repo，则Brad Wilson的答案是错误的。）

对于BDB repo，HEAD（最新）版本是全文，但较早的版本是建立在一系列针对HEAD的差异之上的。这意味着在每次提交后必须重新计算先前的版本。

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

P.S.我们的repo大约有20GB，大约有35,000个修订版本，并且我们没有注意到任何性能下降。

在你的20GB仓库中，它是以FSFS还是BDB存储的？ - Scott Markwell
它现在是FSFS（至少现在是这样）。在我们的仓库存在的第一年左右，它是BDB（FSFS还不存在）。在某个时候，我们进行了转换为FSFS的转储/加载周期。我们没有遇到任何特定的BDB问题，但FSFS在架构上似乎更好（因此FSFS现在是默认值）。 - myron-semack
2
这是一条有趣的信息。我有一个包含73000个文件（大约350 MB）的代码库，但它运行得非常慢。我需要了解他们使用了什么工具。 - Till
4
顺带一提，PHP代码仓库存储在Subversion上，截至撰写此文共有295,197个版本。http://svn.php.net/repository/php/php-src/trunk/。 - jevon
15

Subversion将最新版本以完整文本和向后查看的差异方式存储。这意味着对head的更新始终很快，而您逐步付出的是越来越久远的历史记录。

1
Subversion使用前向增量。 - Ivan Zhakov
6
根据这里的一个回答，你们两个都是对的：“Subversion在FSFS存储库中使用前向增量，在BDB存储库中使用后向增量。” https://dev59.com/Y2oy5IYBdhLWcg3wBJgx - Dave Forgac
5
我个人没有处理过实际项目代码库大于80K LOC的Subversion存储库。我曾经处理过的最大存储库约为1.2G，但其中包括了项目使用的所有库和工具。
我认为日常使用不会受到太大影响，但任何需要查看不同版本的内容的操作可能会稍微变慢。这可能甚至不会被注意到。
现在，从系统管理员的角度来看，有一些措施可以帮助您最大程度地减少性能瓶颈。由于Subversion主要是基于文件的系统，您可以这样做：
- 将实际存储库放在不同的驱动器中 - 确保除svn之外的没有文件锁定应用程序正在驱动器上工作 - 使驱动器至少达到7,500 RPM。您可以尝试获取10,000 RPM，但这可能是过度杀伤力的。 - 如果每个人都在同一个办公室内，请升级局域网到千兆。
这对于您的情况可能有些过度，但这是我通常为其他文件密集型应用程序所做的事情。

如果你发现Subversion已经无法满足需求，那么Perforce将是你向上迈进的下一步。对于非常大的项目来说，它是无疑最快的源代码控制应用程序。

4
我们正在运行一个Subversion服务器，其中包含数GB的代码和二进制文件，已经有超过20000个版本。目前还没有出现任何减速情况。
3
我认为我们的Subversion并没有因老化而减速。我们目前有数TB的数据，大部分是二进制的。我们每天要checkout/commit高达50GB的数据。总共我们目前有50000个版本。我们使用FSFS作为存储类型，并且通过直接连接SVN：（Windows服务器）或通过Apache mod_dav_svn（Gentoo Linux服务器）进行接口交互。
我不能证实随着时间的推移svn会变慢，因为我们建立了一个干净的服务器进行性能比较，我们可以进行比较。我们无法测量到明显的退化。
然而，我必须说我们的Subversion默认情况下非常缓慢，很明显这是Subversion本身的问题，因为我们尝试过另一台计算机系统。
由于某些未知原因，Subversion似乎完全受限于服务器CPU。我们的checkout/commit速率受限于每个客户端15-30MB/s之间，因为一个服务器CPU核心被完全使用。这对于一个几乎空的仓库（1GB，5个版本）和我们的完整服务器（~5TB，50000个版本）都是相同的。调整如将压缩设置为0 =关闭并没有改善这种情况。
我们的高带宽（提供~1GB/s）FC-Array处于空闲状态，其他核心也处于空闲状态，网络（目前为客户端1 GigaBit/s，服务器为10 GigaBits/s）也处于空闲状态。好吧，不是真正的空闲，但如果只使用了2-3％的可用容量，我就称之为空闲。
看到所有组件都处于空闲状态并且我们需要等待工作副本进行checkout/commit，这并不是一件真正有趣的事情。基本上我不知道服务器进程在checkout/commit期间通过完全消耗一个CPU核心做些什么。
然而，我只是试图找到调整Subversion的方法。如果这不可能，我们可能需要切换到另一个系统。
因此：答案：没有，SVN的性能不会退化，它最初就很慢。
当然，如果您不需要（高）性能，那么您就不会有问题。 顺便说一下，以上所有内容都适用于Subversion 1.7最新稳定版本。
我们目前有数千兆字节的数据，大部分是二进制的。我们每天检出/提交高达50吉字节的数据。总共，我们目前有50000个版本。这太不可思议了！自从你在2013年写下这些话以来，你是否看到了通过迁移到更新版本的Subversion解决CPU消耗问题的任何改进（如果你进行了迁移；可能会很麻烦迁移这样一个巨大的仓库）？ - vijucat
3
Subversion只存储两个版本之间的差异(delta)，这有助于节省大量空间，特别是如果你只提交代码（文本）而不是二进制文件（图片和文档）。
此外，我看到很多非常大的项目使用svn，并且从未抱怨过性能问题。
也许您担心检出时间？那么我想这确实是一个网络问题。
哦，我曾经在CVS存储库中处理了2GB+的东西（代码、图片、文档），并且从未遇到性能问题。由于svn是对cvs的极大改进，我认为你不必担心。
希望这可以稍微放松一下您的心情 ;)
2

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

-1

我不确定...... 我正在使用Centos 5.2上的Apache SVN。工作正常。修订号是8230之类的东西...但在所有客户机上，提交速度非常慢，我们必须等待至少2分钟才能处理1kb大小的文件。我说的是一个没有大文件大小的文件。

然后我创建了一个新的存储库。从rev. 1开始。现在运行良好。快速。 使用svnadmin create xxxxxx。 没有检查它是FSFS还是BDB.....

-2

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

我不知道在这些条件下repos是否会有性能问题，但你能够回到一个合理的修订版本。

在你的情况下，你可能想要包括一个验证过程，这样一个团队可以提交到一个团队领导者的repo中，然后每个人都可以提交到团队经理的repo中，再由他们提交到只读干净的公司repo中。在这个阶段，你必须做出清晰的选择，哪些提交必须到达顶部。

这样，任何人都可以回到一个干净的副本，具有易于浏览的历史记录。合并变得更加容易，开发人员仍然可以提交他们想要的混乱。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接