Re: (ITS#5354) slapd repeatedly hangs and stops reponding

[orenl@cs.columbia.edu]

Hi,

Quanah Gibson-Mount wrote:
> --On Thursday, February 07, 2008 2:11 AM +0000 orenl@cs.columbia.edu wrote:
> 
> 
>> # TRY TO SOLVE ISSUES ?
>> threads         32
>> idletimeout     30
> 
> 
> You are likely making your problem worse by increasing the number of 
> threads.  I always advise a setting of "threads 8" in a high read, 
> low-to-medium write scenario.  The more threads you have, the worse the 
> read rate, but the better the write rate.

Yes, I did not that happening. It's just a way to make the problem more
likely to happen, hence helps debugging.

The local database is read-only (used in conjunction to meta). It's a
very small database that rarely changes, and if it does it is re-created
from scratch with "slapadd" from an .ldif file.

> 
>> TLSCipherSuite HIGH:MEDIUM:LOW
> 
> 
> Did you add the patch for fixing TLSCipherSuite issues with GnuTLS 
> (which is what Debian links OpenLDAP against)?

I have no idea about this patch: does it apply to LDAP sources ?
where do I get it from ?

> 
> Get rid of the separate "backend" directives, merge them all into the 
> database area.

I'm not exactly sure what you mean by this; do you mean to only have
one set of TLS.... directive for both backends ?  or have two instances
but place them after the respective database directives ?

> 
> Your cachesize setting for the BDB database also looks bizarrely small.  
> Do you know the actual size of your database?  Because right now, you 
> are telling it to fit everything into 2MB of space.

haha ... well, obviously my main expertise is far from managing LDAP
and or DBs :)
I actually took those value from some default example config file, don't
even remember the source.

The local database is pretty small, it has less than 30 nodes in the
tree, most of which describe posix groups where each group holds on
average less than 10 users. I'd assume 2MB is enough for that.

The remote database (the one to which the meta backend relays requests
is pretty huge, though. But I don't know how to control caching for that
one. What I actually use now is "nscd" to cache on the clients.

How do I check the actual size of the database and whether those settings
are any good ?

All that said, this still does not quite explain why the slapd process
(and threads) entirely hangs at times :(

Many thanks,

Oren.

> 
> --Quanah
> 
> 
> -- 
> 
> Quanah Gibson-Mount
> Principal Software Engineer
> Zimbra, Inc
> --------------------
> Zimbra ::  the leader in open source messaging and collaboration