On Thu, 25 Jul 2002, Blair Zajac wrote:
> I think the problem yesterday of running 'svnadmin lsrevs' on my repos
> and having it run out of memory on the system munched it somehow. I've
> had to revert to the last hot-backup.py saved file. Thank you for that
> script!
>
> On the munched repos, running 'db_recover -ve -h repos/db' works hard
> for a while but never stops and running 'strace -p PID' on it shows this:
>
> select(0, NULL, NULL, NULL, {0, 750000}) = 0 (Timeout)
> select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
> select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
> select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
> select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
> select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
> select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
> select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
> select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
>
> I've put a tar.bz2 of the entire repos up at
>
> http://forsale.orcaware.com/svn-orcaware-144-repos.tar.bz2
>
> in case anybody wants to look at it (there's also an Ford Explorer for
> sale there too :) ). It contains all the log files for the repository.
> Is this something Sleepycat should see?
Probably.
I've run into similar DB fun with cyrus-imap and db4.
In fact, i got databases db_recover would do that on so often i stopped
using it as the backend.
I know *why* it happens. Somehow, the number of locks is out of whack, so
recover keeps trying to acquire an exclusive lock to be able to do
recovery, but can't, since nothing else will ever decrement the number of
locks.
I suspect they have a fix for it, and it's the bug fix noted in the 4.1.XX
changelog as "Fix a bug in DB->rename and DB->remove method calls could
leak a transaction and its locks."
I figured i'd give it another throw as the cyrus imap mail backend
database when they released this version.
--Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 26 14:42:28 2002