Thanks. Your answer was more informative than I had hoped for.
At what point will the server start denying service to incomming
connections? Or will it ever?
It doesn't do so explicitly. When it runs out of descriptors, obviously
it won't be able to handle any more connections.
Does the timelimit (or limit) directive in slapd.conf apply to those
requests that are sitting there waiting to be handled? In other words,
is it possible for a request to time out before it has been handled?
In this case, I would guess that it would still sit in the queue until
a thread picks it up, in which case it would immediately return a
timelimit exceeded error. Is that right?
No, the timelimit controls how long the request actually executes, so it
is based on when the request starts executing. The time the request
spends in various queues is not execution time.
Also, as long as I'm on the topic of threads, is there a
way to calculate the cost of adding threads? If I want to double the
thread pool, how many additional reasources will this take?
There are a number of large chunks of memory allocated per thread. First
is the actual thread stack, which defaults to 1048576 * sizeof(pointer),
so 4MB on a 32 bit machine and 8MB on a 64 bit machine. Also slapd
allocates a 1MB slab per thread for per-operation temporary storage. The
back-bdb/hdb backends also allocate a search stack per thread, for
evaluating indexed filters. As documented in the slapd-bdb(5) manpage,
this defaults to 8MB per thread. Those are the most obvious costs in the
OpenLDAP code; the C library and whatever other libraries you're using
(OpenSSL etc.) have their own per-thread overheads.
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/