Description of problem: I have a long history of running SVN on a fedora server since FC3. I use the last stable version directly downloaded from SVN site that I hand compile on my server. I am running the svnserve daemon to access the subversion repository, this repository weight around 50 GB. Until FC6 everything was working just fine but since I migrated on FC6 I've got a problem which occurs once per day quite randomly. From a client perspective it seems that the server froze, on the server I can see the svnserve processus eating a lot of cpu cycle. At first I let the process run just to see if it was only taking some times to complete, but this is not the case. When this happens I must kill the process, do a recover on the db (quite fast ; a couple of seconds) and then relaunch the process. After that I just do the update on the client machine and everything is ok until the next freeze. It seems that the problem occurs more frequently every morning as several employee try to get the last version from the svn server. Version-Release number of selected component (if applicable): SVN v1.4.2 ; every other component are coming from the fedora install. How reproducible: Steps to Reproduce: 1. Try to do an update 2. SVN process eat a lot of ram and does not accomplish its task. Actual results: svnserve does not return the data and must be killed. Expected results: svnserve returns my data. Additional info: The server is an Athlon 64 3000+ on a socket 754 motherboard with 1gb of ram running the i386 version of FC6.
Please try using the 1.4.2 packages which were issued to the FC6 updates. If you're not using packaged software there's little we can do to help you here. If this is still reproducible we need a exact reproduction recipe. Exactly what command caused svn to consume memory? What was consuming memory, the "svn" client or "svnserve"? What repository backend is being used? What state was the working copy in? etc
I just installed the 1.4.2 package from the FC6 Update, I will keep you informed if it solved the problem. The process who consume the memory is svnserve, the backend used is berkeleydb. For the working copy state it seems that it does not matter (tried with different states).
Even with the package I've got the same problem. I can see several svnserve process, one very high on cpu usage and from a user perspective the server froze. - Every user is using tortoiseSVN. - Problems happens when people update their local copy. - Seems to be tied to concurrent access (as it happens most often in the morning when everybody do update). - When I kill the process, tortoise tell me that "the connection was closed unexpectedly". I just did a "yum update" this morning to see if there was update and as it says that around 150 packages needed update I will do it now and checked if the problem is still there. Normally they are not any custom compiled package anymore on this server (subversion was the only one).
OK. Are you running svnserve in --daemon mode, via xinetd, or via ssh? Can you give the exact command used to invoke svnserv. Can you try to generate a core dump from the svnserve process when it is consuming lots of RAM? Process would be as follows: 1. set "ulimit -c unlimited" from the shell before starting svnserve 2. when you see a "svnserve" consumes RAM, send a SEGV to its pid: kill -SEGV <pid-of-svnserve> There should be a core dump in / - if you don't mind uploading this (it may reveal contents of your repository), bzip2 it and attach it to this bug report - check the "private" box to keep it non-public. Otherwise, generate a backtrace as follows: yum --enablerepo=updates-debuginfo install subversion-debuginfo \ apr-debuginfo apr-util-debuginfo httpd-debuginfo glibc-debuginfo \ db4-debuginfo gdb /usr/bin/svnserve /core.<pid> ... (gdb) bt and attach the output of that command.
The exact command to launch svnserve is : sudo -u apache svnserve -d -r /path_to_repository (well we sudo as apache user as we are running trac on the same computer with access to this repository, but my problem existed before the installation of trac). I just tried the "kill -SEGV" this morning, but my first interrogation was that it seems that svnserve spawned several processes, so I sent the kill message to the one consumming all my cpu time. But this did not produce a core dump, certainly because I did not have the ulimit command launched prior to svnserve. This is the case now, so I will keep you informed when I collect more data.
Is this reproducible in the 1.4.3 packages now in the updates?
I would be glad to answer but since then I moved the database on another disk on the same server and it seems that this solved the problem.
No problem, let's presume this was some lower-level issue then.
From what I've read when I was searching the net it seems to be a "low level issue with BerkeleyDB which explain why you should prefer the filesystem version".