巨大的svn签出使apache（dav_svn）消耗服务器上的所有内存-有什么提示吗？

服务器上的apache2/dav_svn/ssl/subversion中是否有任何设置可以使整个系统在大签出时性能更好（或者至少不会消耗所有内存）

我对如何降低内存消耗的建议特别感兴趣

提出这一问题的理由：

上周我们的svn服务器出现了一个问题——它停止响应所有请求，管理员通知我们所有内存都被apache占用。我们在apache上使用mod_dav通过ssl访问subversion存储库

内存不足的原因是我的一位同事进行了一次约2.5GB的大签出，其中可能包含一些大小超过500MB的文件。我听说他尝试了多次，所以可能有几个进程挂在服务器上

服务器管理员说您不应该在subversion中存储这么大的文件，但我不同意这一点——如果这些文件对项目至关重要，我总是希望它们存储在存储库中。

在许多情况下，“性能更好”和“消耗更少的内存”是不兼容的

通常，当使用更多内存（例如缓存）时，性能会得到提高。因此，虽然我理解您的问题是如何保持内存消耗低，但请注意，SVN将因此而变慢

服务器管理员在SVN中保存大量（是二进制的吗？）文件的想法是正确的。SVN主要用于源代码-小文本文件。如果您需要在某个地方维护相关数据、输入、测试数据、资源、第三方依赖项等的版本，我建议您在某个共享位置创建一个二进制存储库，并使用目录结构+可能的符号链接来反映svn repo中存在的版本控制

保持SVN尽可能精简（但不是更精简！）确实有好处。SVN因其设计而出了名的执行签出缓慢（例如，与非常便宜的分支相比，它是一个非常繁重的操作）。更快的签出和指责等转化为更快的开发周期。因此，我觉得在一些备份的网络共享上“手动”维护一个非代码存储库是值得的，而不是将所有内容都保存在svn中

还要记住，你不能把你想要的一切都放在svn中。你没有把平台sdk放在那里，对吗？因此，使用外部存储库可以为您提供一个更完整的解决方案，允许您在其中放置更多的内容

---

另一个不相关的注意事项是：最便宜的解决方案可能只是增加更多的RAM。事实上，我已经尝试过基于“RAM磁盘”的SVN存储库解决方案，它们的速度非常快

这是SVN/Apache/SSL的一个众所周知的问题

有一些变通办法，但目前似乎没有100%的解决办法。阅读了解更多信息

一些拟议的解决办法：

• 使用VisualSVN服务器1.6.3（win32、非SSL和带SSL）
• 不要使用SSL
• 使用SSLSessionCache shm:key指令
• 使用匹配的SVN客户端和服务器
• [……]

---

感谢您的回复。虽然我同意更小的svn更好，但是在另一个位置存储数据版本的额外工作对我来说是不值得的。特别是因为这会让人们完全停止使用版本控制。但你仍然将第三方代码存储在一个单独的位置，你只是没有以一种有组织的方式，而是以一种隐含的方式（因此是有问题的方式）来做。e、 g.JDK、平台SDK、STL实现等。我认为如果你对svn中哪些内容属于/不属于有明确的规则，你就可以了。我同意这是关于第三方代码/数据的，但这是内部创建的东西，可能由多个开发人员修改，它需要版本控制。将它转移到一个单独的位置意味着我们将建立自己的版本控制系统，我宁愿把时间花在其他事情上。它几乎不是一个版本控制系统。简单的事实是，没有SCM提供完整的解决方案。您总是需要在某个地方保存一大堆不是源代码但却是构建过程一部分的东西。不知怎的，500MB的文件听起来不像源代码。什么是SVN和apache版本？Apache2-不知道SVN版本。我下周再查。