2

在我们的实时服务器上运行svn update有时需要超过 15 分钟才能完成。

  1. 我们的存储库非常小，大约 1Mb 约 100 个文件（这是一个小网站）
  2. 我们有几个开发人员同时进行提交/更新，这工作得很好
  3. 我们更新了服务器上的所有更改（仅更新svn update），而且运行速度非常缓慢
  4. 我们从来没有svn commit从服务器上做过（它应该是我们网站的只读版本）

随着时间的推移，它在服务器上的执行似乎变得越来越慢svn update，即使它只是一个需要更新的文件。我开始认为我们服务器上存储库的“年龄”与它有多慢有关？如果是这样，我们可以做些什么来加快速度？

更新#1

我仍然认为“年龄”与svn update缓慢有关，但可能必须考虑当服务器上的存储库“年龄”时实际发生的情况......

我认为这是以下原因：

  1. 自 2010 年 1 月以来，我们已经检查了 WebsiteA 上的存储库（使用svn checkout）并定期更新（使用）svn update
  2. 我们还以相同的方式在 WebsiteZ 上检查了相同的存储库，但这发生在几天前，即 2012 年 7 月
  3. WebsiteA 和 WebsiteZ 都在同一个物理服务器上，并且都使用同一个存储库
  4. 在 WebsiteA 上运行svn update以从修订版 100 更新到 101 需要 20 多分钟
  5. 在 WebsiteZ 上运行svn update以从修订版 100 更新到 101 只需几秒钟

我能看到的这些网站之间的唯一区别是 WebsiteA 存在的时间更长一些。WebsiteA 中可能有一些额外的文件（缓存内容），尽管这非常少（少于 20 个文件），并且包含缓存文件的目录已使用 svn:ignore 设置为忽略所有文件。

我想我不能排除网络问题，但我假设 WebsiteA 和 WebsiteZ 将运行相同的防火墙设置，如果有规则，它将是“阻止”而不是“延迟”。由于两个网站都在同一台服务器上，我认为它们都应该在相同的时间内更新网络问题。

更新#2

值得注意的是，如果我们这样做svn update file.txt，它会运行得非常快。就好像 svn 正在比较我们在目录中的所有内容，只是为了找出要更新的内容。

更新#3

我们最终升级了 svn 并升级了所有签出的版本。svn update现在似乎跑得更快了，手指交叉保持这种状态。谢谢大家帮忙！！

更新#4

当然，重新结帐可以解决问题，但只能持续几天/几周。我想今天终于找到了svn慢的原因。我们使用 Zend_Auth 并在每个页面上调用 Zend_Auth::hasIdentity() 来检查用户是否登录。这个调用创建了一个会话，而会话又在服务器上创建了一个会话文件。如果浏览器（或 googlebot）在关闭 cookie 的情况下浏览，我们会为每个请求创建一个会话文件。因此我们的会话目录有数百万个文件。我们删除了目录中的文件，并修复了通过在调用 hasIdentity() 之前检查 cookie 是否已设置来确定用户是否登录的方式。svn现在更新运行时间 <30 秒。

4

2 回答 2

1

我建议使用svnadmin dumpand来重建 subversion 存储库（在备份它之后！） svnadmin load，例如，如手册中所述。可能是通过旧版本升级时存储库中存在一些异常。你说这是一个旧的存储库，所以这里可能就是这种情况。执行转储 -> 加载循环意味着 Subversion 可能会以当前格式创建更优化的存储库。

于 2012-07-13T09:57:04.667 回答
0

SVN 将源文件和等量的元数据（.svn 目录）写入本地磁盘。如果网络不是问题，您还可以检查磁盘性能如何。我遇到过 SAN 磁盘很慢的情况（网络延迟、本地和远程数据之间的错误检查等）并且导致 SVN 延迟。通常在这种情况下，本地磁盘应该工作得更好。您可以尝试以下方法：

  • 如果可能，请svn export在与存储库和 svn 守护程序运行的同一台服务器上进行操作。如果它在那里运行得更快，那么它是网络或磁盘。
  • 如果svn export在其他客户端/开发机器上运行得更快，那么它应该是磁盘。

我怀疑存储库的年龄是否与性能有关。

希望这可以帮助。

于 2012-07-11T16:09:21.480 回答