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

Re: slapd does not answer in time

Quanah Gibson-Mount wrote: 
--On Friday, February 22, 2008 10:37 AM +0100 Hans Moser
<hans.moser@ofd-sth.niedersachsen.de>  wrote:

Pierangelo Masarati schrieb:

There is no connection number limit (except for OS limits on number of
file descriptors and so); bu 65 replicas re-syncing simultaneously, with
operations that may require hours, will eat up all threads if configured
as the default.  If you need to have so many replicas, you might
consider unloading the master from bulk search load, dedicating it to
centralizing writes, and configure it with lots of threads, so that it
can simultaneously deal with syncs and writes (e.g. 8 threads plus the
number of consumers, to be conservative).

Thanks, I increased the number of "threads".
Should I increase "concurrency" too?


Personally, I think this was bad advice, as I've seen there be serious
problems in the past with a high number of threads (tons of contention).
As recently discussed, there hasn't been any proven benefit from going
beyond 16 threads with OpenLDAP.

Don't be too hasty. The results I was discussing was for a particular case, where the individual operations are very fast. (In fact back-null is typically so fast that a few threads can handle requests from many many SLAMD clients without any delay. Even with the server configured for 16 threads I seldom saw slapd spawn more than 3 or 4 in those tests, until the load reached hundreds of clients.)

But in a situation where you have many slow operations (such as a complete syncrepl refresh on a large DB) you need more threads, just as Ando recommended.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/