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

Re: (ITS#3227)

> Pierangelo Masarati wrote:
>>>OK.  I recompiled with "--enable-threads=no" and still get crashes.
>>>Should that eliminate threads as a problem?
>> There's no --enable-threads switch in OpenLDAP's configure.  There's a
>> --with-threads one.
> Whoops!
>> In any case, I think back-ldap definitely needs threads and, provided
>> the
>> system threads are not buggy, their use with slapd should be relatively
>> safe and beneficial in all cases.  I think you just need to boost the
>> number of simultaneous threads your slapd can handle.  The default is
>> 16,
>> and if you want to deal with 512 simultaneous connections you could try
>> "threads 64" or "threads 128" (if your hardware can stand it, i.e. you
>> are
>> using a 2/4 CPU system with a lot of ram and overall good performance,
>> including network bandwidth).  Otherwise, you cannot simply accept so
>> many
>> simultaneous connections with your hardware, sigsegv or not.
> Excellent.  With "threads 128" our dual CPU (+SMP) machine handled the
> 4500 test queries without crashing!
> We've actually been having our production LDAP server crash all the time
> (at least once a day) due to what I'm hoping is this problem.  I'm going
> to increase the number of threads there and see if that helps.
> Here is a theory for you:
> Does the BDB backend accept queries only as fast as it can actually
> resolve them, whereas the LDAP backend accepts queries as soon as they
> are received and start queuing them up?

I might not be the most appropriate person to answer your question; as far
as I can tell, the frontend accepts connections, and concurrently handles
as many connections as threads are available in the main pool (that's one
of the reasons for not compiling --without-threads...).  Connections are
handled by calling backends as appropriate.  Back-bdb has to do some work,
while back-ldap forwards requests and waits for response.  I guess if the
remote server is not much responsive, back-ldap may submit too many
concurrent requests and idle while they're answered.  Here the frontend
starts queuing further connections.  In any case, the frontend that
accepts and queues connections is the same for all backends, so at this
level there should be no difference.


Pierangelo Masarati

    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497