[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: Long query times: OpenLDAP 1.2.7 + BDB 2.7.7 + Solaris 7

I'm also currently seeing strange problems on a build
of OpenLDAP 1.2.6 with BDB 2.7.7 on Solaris 7.

The symptom I'm seeing is the slapd process is processing
add requests very very slowly (about 1 every 3 seconds).

>From looking at the output being logged by slapd, and
peering into the innards of the running slapd process
using truss, this seems to be as a result of problems
with the database engine. The system calls just before
the pause between entries seems to imply that slapd
is attempting to open some of the index files, and
failing as they are already there, then logging an
error (returned by BDB) that the open failed,
"Resource temporarily unavailable".

My gut feeling on this is that it's a threading issue,
and that one of the threads has somehow placed a lock
on the file and then become blocked by something else.

The index files in question are mostly 0 length, and
the modification dates aren't changing.

A similar (possibly the same) problem is manifesting in
ldif2ldbm loads from dumps of (believed good) directories,
where the "Resource temporarily unavailable" message is
printed, and one or more of the index files ends up
containing data, but ldbmcat outputs a screenful of blank
lines. This was first noticed when searches with scope
subtree and onelevel weren't working (returning empty
results, but no error), and the cause was the id2children.dbb
file not containing the correct index.

These problems do not seem to be present in a build of
OpenLDAP 1.2.6 using gdbm (our current production

I'm about to try rebuilding the 1.2.6 distribution with
BDB 2.7.7 and GNU Pth 1.1.5 to see if this clears up
these problems.