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.

Quanah Gibson-Mount writes:

--On Friday, February 22, 2008 11:50 AM -0800 Howard Chu hyc@symas.com wrote:

...

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.

I'm still quite skeptical given what I've seen in the past. ;)

I've mentioned before that yanking up 'threads' in slapd.conf did help at our site some years ago. Fewer requests took abnormally long time that way. (Possibly more threads degraded the _average_ response time, but that was fast enough anyway.)

Some server stats, maybe we were half as big/active then: 60-90 new connections and 300-500 requests per second. (Just samples just now and a few other times). Can exceed 6000 concurrent connections. 340000 entries. 5 bdb databases, though we used ldbm back then.

Dave Horsfall wrote:

On Fri, 22 Feb 2008, Quanah Gibson-Mount wrote:

...

As recently discussed, there hasn't been any proven benefit from going beyond 16 threads with OpenLDAP.

There is if all your connections are anonymous.

Huh? Sounds like a non-sequitur to me...