On Saturday 22 October 2005 08:12, Marius Gedminas wrote:
> 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
> over svn+ssh.
>
> 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.
Be careful when doing such things. BDB is sensitive to platform, OS, and
version of the library. If any of those things changed (and it appears that
at least the version of BDB might have changed), then you might have run into
a side effect that prevented you from dumping the repository.
> 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.
That only touches part of the database. Try 'svn diff -r5:6 url:://to/repo'.
That will pull out the entire changeset for that revision.
> What do I do now?
You have a couple of choices. If you can tar the repo up someplace, and email
me the link, I can take a closer look at the problem. In the event you can't
do that (because of intellectual property concerns), then there is something
you can try (and it might be good to do so first).
Make a copy of the repository, and attempt then a catastrophic recovery:
db_recover -c -v -h /path/to/repos/db. I believe there was one occassion
where I saw a similar behavior, and a catastrophic recovery fixed the
situation. To be safe, I'd dump and load the repository if the catastrophic
recovery was successful.
HTH.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 2 11:27:32 2005