With these pth changes, multiple-writers appear to work as expected.
However, there is another problem, this time with readers. An
ldapsearch displays a part of the total number of entries, then
hangs. Initiating another ldapsearch causes the first one to
continue some more, after which both hang again.
I suspect the select loop in daemon.c was somehow blocking.
Rebuilding OpenLDAP with --without-yielding-select seems to
have cured the reader problem. Does this make sense ?
BTW, make in the tests/ directory finishes one test, but fails
on the the second with an "address in use" error. Also confirmed
with netstat -a, although the slapd process is not running.
Vinod.
-----Original Message-----
From: wesley.craig@umich.edu [<mailto:wesley.craig@umich.edu>mailto:wesley.craig@umich.edu]
Sent: Thursday, May 18, 2000 5:26 PM
To: Vinod Nair
Cc: openldap-software@OpenLDAP.org
Subject: Re: PTH support in OpenLDAP 1.x
> From: Vinod Nair <vnair@broadjump.com>
> On Solaris2.6, with pre-emptive threads, I've seen "multiple
> writers" scenario occasionally core dump (1.2.10) or hang (1.2.9).
> This is with the DirMark benchmark. Do you have multiple writers in your
> setup ?
Yes. And we do see occasional crashes. We really have no choice, tho,
given our high load. Also, our crash rate was no different with PTH
than with pthreads. Numerous bug fixes have been applied since I tried
it, tho, so PTH may improve reliability.
> By "administrative limits on searches" were you referring to
> the sizelimit or timelimit parameters in slapd.conf. I (and
> I'm sure others on the list too) would like to hear about
> your performance enhancements.
I've implemented candidate limits, different from size or time limits.
During search, particularly on un-indexed attributes, the server loops
through large lists of entries. Given the high time limit we set,
searches on unindexed attributes start a rather long lived thread which
is unlikely to produce useful results. We added code to count the
number of entries examined, the number of entries returned, and what
the final result was. We found that searches which examined more than
1000 entries were unlikely to ever return any result, and the final
return was invariably "time limit exceeded".
A candidate limit allows us to return "time limit exceeded" (in LDAP v3
we would return "administrative limit exceeded") in a much shorter
time, after having expended fewer resources.
> ./configure --with-ldbm-api=db2 \
> --with-ldbm_type=btree \
> --with-threads=pth \
> --enable-rlookups=no
I believe --with-ldbm_type=btree is the default.
:wes
<<<<