如何提高 Windows Subversion 客户端更新性能？答案

【问题标题】：How do I improve Windows Subversion client update performance?如何提高 Windows Subversion 客户端更新性能？
【发布时间】：2015-04-16 00:17:33
【问题描述】：

如何提高 Subversion 客户端更新性能？它似乎是客户端上的磁盘绑定。

详情：

CollabNet Windows 客户端版本 1.6.2 (r37639)
Windows XP SP2
3 GB RAM，PF 使用量约为 1 GB，系统缓存为 1.1 GB。
磁盘已启用写入缓存
更新需要 7-15 分钟（更新时间很少）。
Checkout 有 36,083 个目录/文件（来自 svn 列表）
存储库有 58,750 个修订版。
结帐大约需要 2.7 GB
性能监视器显示更新期间磁盘写入时间百分比保持在 90% 附近。
Max Disk Read Bytes/sec 达到 12.8M，写入达到 5.2M
CPU、页面文件使用率和网络使用率都很低。
观察服务器性能似乎表明它不是瓶颈。

除了获得更快的磁盘（尤其是配置更改）之外，我对答案特别感兴趣。

一些建议的更新：

我需要整个东西，所以稀疏的目录不起作用。
另一个客户端 (TortoiseSVN) 也需要 7 分钟
已配置 TortoiseSVN 图标覆盖，因此它们不会导致问题。
防病毒配置为跳过该目录，如果它不是导致问题的原因。

【问题讨论】：

我猜你可能已经搞定了，但是像 McAffee 和 AVG 这样的防病毒程序会扫描每个磁盘的读/写。
我在 Windows 下运行时遇到了同样的问题。使用类似硬件，Linux 客户端在新结账时速度提高了 5 倍。我看到的信息将其归咎于 Windows 磁盘访问效率低下，无法解决问题。
TortoiseSVN file overlay performance - are there any ways of improving it? 的可能副本。

标签： performance svn

【解决方案1】：

我的经历完全一样。最近用 svn 替换了 Perforce，但如果我们不能克服 Windows 上的性能问题，我必须考虑另一种工具。使用 svn 1.6.6、Win XP 和 Vista 客户端。红帽服务器。我的观察与你的一致：

大量磁盘写入活动。
防病毒不是瓶颈。
无论使用什么 svn 客户端。
没有服务器或网络瓶颈。

补充信息在以下方面的操作速度提高 3 倍以上：

Linux (Ubuntu)。
Linux (Ubuntu) 在 Win Vista 主机的 VirtualBox 上运行。
Win XP 在 RedHat 主机的 VMWare 上运行。

【讨论】：

【解决方案2】：

您需要工作副本上的所有存储库吗？如果您真的只关心树的特定部分，请查看 Subversion 的 Sparse Directories（又名“稀疏检出”）功能。它允许您操作您的工作副本，因此它只包含那些感兴趣的目录。

例如，您可以使用它来修剪文档、与安装程序相关的文件等。根据您在本地计算机上的真正需要，采用这种方法可能会大大缩短您的等待时间。

【讨论】：

【解决方案3】：

尝试 svn 客户端版本 1.5。。它对我的 Vista 笔记本电脑有帮助。 1.6 版。 非常慢。

【讨论】：

【解决方案4】：

这更有可能是您的网络和移动的数据量以及您的客户端。你在用乌龟吗？移动这么多数据时，我发现自己有点慢！

【讨论】：

我使用的不是 Tortoise，而是 CollabNet 命令行客户端。性能监视器也显示非常低的网络使用率。他们还有什么具体的东西我应该检查一下是否是网络问题？
您可以在本地计算机上创建一个存储库，并在那里签入您的代码。如果是网络问题，如果是本地的，它应该会更快。但我猜这是磁盘问题。

【解决方案5】：

你在使用 TortoiseSVN 吗？如果是这样，图标叠加层会减慢操作速度。如果你去 TortoiseSVN 设置/图标覆盖，你可以调整几个设置来控制你想要使用覆盖的级别，包括完全关闭它们。看看这是否会影响你的表现。

【讨论】：

我已经对它们进行了调整以使用 shell，这样我就不会受到后台处理的影响。我刚刚测试了完全关闭它们，花了 7 分钟，所以它似乎没有帮助。

【解决方案6】：

您是否运行使用读写扫描的病毒检查程序？那真的可以让它爬行。如果是这样，请将其关闭，看看是否有帮助。如果有帮助，大多数扫描程序都会有办法排除特定目录。

【讨论】：

我已经将它配置为在结帐时忽略目录。作为测试，我完全禁用了它，但仍然需要 7 分钟。

【解决方案7】：

似乎没有人指出我经常认为是设计缺陷的一个原因。 Subversion 为离线操作创建第二个“原始”的结帐副本。如果您要检出 4G 的文件，实际上是在将 8G 写入磁盘。

将结帐与导出进行比较。这将向您展示编写第二份副本时的巨大差异。

对此你无能为力。

【讨论】：

这可能不会影响更新性能。顺便说一句，“设计缺陷”会在与服务器断开连接时启用差异，因此它确实有好处。

【解决方案8】：

升级到svn 1.7

来自Discussion of Slow Performance of SVN Update：

svn 1.6 的更新过程是这样的：

搜索整个工作副本，看看现在有什么，然后锁定它，以便在接下来的步骤中没有人改变答案

告诉服务器

从服务器接收您需要的任何新内容，并将更改应用到文件中

再次递归整个工作副本，将其解锁

如果目录和文件很多，第1步和第4步可以占用一个很多时间。这与您对 long 的观察一致没有网络流量的延迟。

在 svn 1.7 中更改了工作副本格式。现在所有元信息都存储在工作副本根文件夹中的 SQLite 数据库中，无需再执行在svn update 期间花费大部分时间的步骤 1 和 4。

【讨论】：