Re: (ITS#5189) slapadd -q breaks db_stat -c

[hyc@symas.com]

Hallvard B Furuseth wrote:
> hyc@symas.com writes:
>> h.b.furuseth@usit.uio.no wrote:
>>> quanah@zimbra.com writes:
>>>> You have to run slapd at least once before using the db_stat tool
>>>> after using slapadd -q.  This is a known feature of using -q.
>>> Ah, need doc fix in slapadd.8 then.
>> What exactly are you trying to do?
> 
> Playing around, mostly.
> 
>> slapadd -q disables locking,
> 
> I don't see that in the doc.  It's reasonable to infer, except I have no
> idea why even slapadd (without -q) needs so many.  I couldn't find an
> explanation of what does use locks and lockers (FAQ file 893 doesn't
> say), thus not how many I will need and which of these limits is fatal
> if I have too few.  Can experiment to find out the latter, of course.

These are backend-specific considerations. Feel free to file an ITS against 
the slapd-bdb(5) manpage if you wish.

In back-[bh]db there are typically up to two transactions per operation, and 
each transaction uses a single locker. There's also a single reader locker per 
thread. So at most you need 3 lockers per configured server thread. The BDB 
default of 1000 is generally more than enough.

Any operation will acquire a lock for every single DB page it touches. The 
more work that an operation needs to do, the more pages it will touch, the 
more locks it will need. If you write an entry that has many indexed 
attributes, or if you have substring indices on attributes with lengthy 
values, you will need many locks in a single operation. While the number of 
pages simultaneously held open will depend on the actual distribution of data 
in the database, an operation will generally need at least one lock per DB 
file. So, one for a dn2id lookup, one for an id2entry lookup, and one for each 
defined index. In most cases that's all, but substring indices will generally 
need a number of locks proportional to the length of the strings being indexed.

> Sleepycat messages can be scary.  I came from the slapadd "wrong dynamic
> library" or message or whatever it was which the mailinglist says is
> cured with more locks & lockers, so I increased those and just got
> another error message (this ITs).  So apparently, something still wrong.

I'm not familiar with that message or advice.

> "Not configured for the locking subsystem" sounded like a permanent
> problem with the database build, not that it would get "reconfigured" to
> support locking when needed.  Hence this report.  Oh well.

The message said The Environment is not configured for locking. It didn't say 
the BDB library. Really there's nothing mystical or spooky here, and if you've 
actually read the BDB documentation you'll know what The Environment refers 
to. If you're using back-[bh]db without having read the BDB documentation, 
despite all the recommendations to do so, you deserve to be scared.

>> so of course there's nothing for db_stat -c to report.  There's no
>> breakage here.
> 


-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP     http://www.openldap.org/project/