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.