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

RE: PTH support in OpenLDAP 1.x

Actually, I did build Pth with the --enable-syscall-soft option. The "ldapsearch blocked"
problem happens inspite of that.
--without-yielding-select seems to have helped though.
Thanks, Vinod.
-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Friday, May 19, 2000 1:39 PM
To: Vinod Nair
Cc: 'wesley.craig@umich.edu'; Vinod Nair; openldap-software@OpenLDAP.org
Subject: RE: PTH support in OpenLDAP 1.x


env CPPFLAGS="-DPTH_SYSCALL_SOFT=1" ./configure --with-threads=pth

as you likely didn't build GNU Pth with --enable-syscall-soft.

I'll update configure to remove this requirement.


At 01:19 PM 5/19/00 -0500, Vinod Nair wrote:


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.


-----Original Message-----

From: 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

> 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.