You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Sander Striker <st...@apache.org> on 2002/05/16 01:09:01 UTC
DB_CONFIG on svn.collab.net
Hi,
Today I wanted to update some a subversion wc that was
very outdated. The server didn't seem to like it and
issued the familiar 'cannot allocate memory' error.
After that the repos locked up and Ben had to run
db_recover to unlock it again.
That made me think about a DB_CONFIG in our db environment
in the svn repos on svn.collab.net. Since the defaults
are all set to 1000, maybe doubling makes sense:
# This is the configuration file for the Berkeley DB environment
# used by your Subversion repository.
### Lock subsystem
#
# Make sure you read the documentation at:
#
# http://www.sleepycat.com/docs/ref/lock/max.html
#
# before tweaking these values.
set_lk_max_locks 2000
set_lk_max_lockers 2000
set_lk_max_objects 2000
Thoughts?
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: DB_CONFIG on svn.collab.net
Posted by "Stephen C. Tweedie" <sc...@redhat.com>.
Hi,
On Fri, May 17, 2002 at 12:10:39PM -0400, Kevin Pilch-Bisson wrote:
> > At the very least, would it be possible to add some form of error
> > flagging so that when the lock limit is exceeded, we get a useful
> > error back instead of the current "out of memory" error that the user
> > sees?
>
> That's a good point. Where do you think such an error flag should go? It's
> not clear to me whether or not we could actually check db4 for this error
> specifically, but we could maybe make a FAQ saying "If you see ENOMEM errs,
> try this before giving up...
Hmm, it's not clear from the db4 documentation exactly which error db4
is going to return when this happens. If we could trap exactly that
error, then appending a line like
EFOO may also indicate you need more locks in the db;
see <url> for info
to the error output would at least prevent the user from giving up in
despair!
Cheers,
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: DB_CONFIG on svn.collab.net
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
On Fri, May 17, 2002 at 05:02:37PM +0100, Stephen C. Tweedie wrote:
> Hi,
>
> On Thu, May 16, 2002 at 01:36:05PM -0500, Karl Fogel wrote:
> > "Sander Striker" <st...@apache.org> writes:
> > > That made me think about a DB_CONFIG in our db environment
> > > in the svn repos on svn.collab.net. Since the defaults
> > > are all set to 1000, maybe doubling makes sense:
> >
> > Well, I read http://www.sleepycat.com/docs/ref/lock/max.html, and came
> > away with appx 5% more understanding than I had before :-).
> >
> > I upped them to 2000 in our fs initialization code (see rev 1971);
> > haven't changed the svn.collab.net repository, as it will get upgraded
> > before long anyway.
>
> At the very least, would it be possible to add some form of error
> flagging so that when the lock limit is exceeded, we get a useful
> error back instead of the current "out of memory" error that the user
> sees?
That's a good point. Where do you think such an error flag should go? It's
not clear to me whether or not we could actually check db4 for this error
specifically, but we could maybe make a FAQ saying "If you see ENOMEM errs,
try this before giving up...
>
> Trying to import a kernel tree was repeatedly giving me this error.
> Even once it was pointed out that this was a lock error, not really
> ENOMEM, all that my reading of all the relevant svn and db4
> documentation revealed was the setting of new values in DB_CONFIG.
> That did not fix the problem --- there's a magic db4_recover(8)
> invocation required before the database's locks are expanded.
>
> In other words, the current error is incredibly misleading, and the
> cure is documented only in the subtle depths of mailing archives as
> far as I can see. It's going to be a common problem for svn users,
> and the current impression people will take away from it is "oh,
> subversion just falls apart on large repositories."
>
> Cheers,
> Stephen
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: DB_CONFIG on svn.collab.net
Posted by "Stephen C. Tweedie" <sc...@redhat.com>.
Hi,
On Thu, May 16, 2002 at 01:36:05PM -0500, Karl Fogel wrote:
> "Sander Striker" <st...@apache.org> writes:
> > That made me think about a DB_CONFIG in our db environment
> > in the svn repos on svn.collab.net. Since the defaults
> > are all set to 1000, maybe doubling makes sense:
>
> Well, I read http://www.sleepycat.com/docs/ref/lock/max.html, and came
> away with appx 5% more understanding than I had before :-).
>
> I upped them to 2000 in our fs initialization code (see rev 1971);
> haven't changed the svn.collab.net repository, as it will get upgraded
> before long anyway.
At the very least, would it be possible to add some form of error
flagging so that when the lock limit is exceeded, we get a useful
error back instead of the current "out of memory" error that the user
sees?
Trying to import a kernel tree was repeatedly giving me this error.
Even once it was pointed out that this was a lock error, not really
ENOMEM, all that my reading of all the relevant svn and db4
documentation revealed was the setting of new values in DB_CONFIG.
That did not fix the problem --- there's a magic db4_recover(8)
invocation required before the database's locks are expanded.
In other words, the current error is incredibly misleading, and the
cure is documented only in the subtle depths of mailing archives as
far as I can see. It's going to be a common problem for svn users,
and the current impression people will take away from it is "oh,
subversion just falls apart on large repositories."
Cheers,
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: DB_CONFIG on svn.collab.net
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
"Sander Striker" <st...@apache.org> writes:
> That made me think about a DB_CONFIG in our db environment
> in the svn repos on svn.collab.net. Since the defaults
> are all set to 1000, maybe doubling makes sense:
Well, I read http://www.sleepycat.com/docs/ref/lock/max.html, and came
away with appx 5% more understanding than I had before :-).
I upped them to 2000 in our fs initialization code (see rev 1971);
haven't changed the svn.collab.net repository, as it will get upgraded
before long anyway.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org