[Date Prev][Date Next]
Re: (ITS#5189) slapadd -q breaks db_stat -c
Hallvard B Furuseth wrote:
> email@example.com writes:
>> firstname.lastname@example.org wrote:
>>> email@example.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/