我认为我们的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最新稳定版本。