TechnoSophos wrote:

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