[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Db4 shared mem, ENOMEM on large import

From: Ben Collins <bcollins_at_debian.org>
Date: 2002-03-08 21:55:30 CET

On Fri, Mar 08, 2002 at 09:30:26AM -0500, Ben Collins wrote:
> Well, in response to the memory usage, the import of the tree I am doing
> now only takes 103megs instead of 300megs of memory. Still getting the
> failures in close_edit (more specifically in svn_fs_commit_txn when
> calling svn_fs_retry_txn, on down into svn_fs_rep_contents_size).
>
> After placing an abort just before the error return (and running under
> gdb) I get this:
>
> bottom:/usr/src/svn/repo/db# db4.0_stat -d strings
> db_stat: Lock table is out of available locks
> db_stat: open: strings: Cannot allocate memory
> db_stat: Database handles open during environment close
> db_stat: dbenv->close: Invalid argument

Increasing env->set_lk_max_{locks,lockers,objects} to 5000 fixed the
problem.

Now, I do not think that any of those numbers are the problem. We never
hit any of those limits. The problem is the shared mem segment for
locking. Originally it is ~380k. After setting just the objects to 5000,
it increases that to ~870k (which wasn't enough). Setting all of them
to 5000 made the lock shared mem segment 1.7megs, which worked.

I don't think we are leaking locks, but we may be doing too much work
(I'm not familiar with the internals of the locking scheme in bdb) at
once.

-- 
 .----------=======-=-======-=========-----------=====------------=-=-----.
/       Ben Collins    --    Debian GNU/Linux    --    WatchGuard.com      \
`          bcollins@debian.org   --   Ben.Collins@watchguard.com           '
 `---=========------=======-------------=-=-----=-===-======-------=--=---'
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 8 22:00:20 2002

This is an archived mail posted to the Subversion Dev mailing list.