I keep bits of my home directory in a Subversion repository. It has 600
revisions and occupies 250 megs of disk space. It uses bsddb. I kept
it on a server running Subversion 1.1.4 from Debian sarge, and committed
stuff to it from my laptop running Subversion 1.2.0 from Ubuntu breezy
Usage pattern was normal -- a number of small checkins. I have added a
bunch of files totaling 90 megs in rev 571, and another bunch totaling
76 megs in rev 597.
Two days ago I tried to commit a small patch, but the commit timed out.
I retried a few times, then gave up assuming network problems.
Yesterday the same thing happened, and I sshed into the server to take
a look. I saw a bunch of svnserve processes. I killed them, ran
svnadmin recover just in case. Then I decided to do 'svn up' in the
root of the checkout on my laptop. Nothing happened for a while, but
after a few minutes svnserve on the server side ate all available RAM
and swap, and caused the kernel to invoke the OOM killer. The server
has 512 megs of RAM and 2 gigs of swap!
I thought those two big commits were causing a problem. I decided to
use svnadmin dump and svndumpfilter. svnadmin dump dumped 5 revisions
successfully and started eating all the memory while processing rev 6.
I killed it. svnadmin verify acts likewise.
I scp'ed the repository to my laptop, ran svnadmin recover for good
measure, and retried svnadmin dump with Subversion 1.2.0. The same
thing happened. svnadmin eats about 300 megs of RAM in 20 seconds, then
I kill it.
I have tried dumping random revisions with svnadmin dump -r N
--incremental, and looking at their size with wc -l. There are 28
revisions out of 600 that I cannot dump without running out of RAM:
6, 7, 17, 25, 32, 39, ..., 229, 276, 458, 595. The two large commits
that I suspected (571 and 597) are not among them.
I can access all log messages with svnlook log -r N with no problems.
What do I do now?
Any time somebody tells you that you shouldn't do something because it's
"unprofessional," you know that they've run out of real arguments.
-- Joel Spolski
Received on Sat Oct 22 14:15:01 2005