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

Re: Connection-handling threads

John Morrissey wrote:

I run a cluster of several dual-processor OpenLDAP servers that are starting
to saturate one of their CPUs with OpenLDAP's connection-handling thread.

The machines are healthy otherwise (memory consumption, disk I/O,
interrupts, etc.) so this single connection handling thread is the current
bottleneck in our installation. AFAICT, once this single thread starts
consuming an entire CPU, we've hit the wall even though the bulk of the
other CPU is idle.

Yes, this is definitely a bottleneck. The IBM folks are currently experimenting with different approaches to improve the situation.

I've considered running two slapd instances, one for each binding, but that
requires twice the disk space and twice the memory consumption. Ideally, I
would like to bind to two ports/interfaces and split connection handling
between two threads, one thread per bound socket. Our load balancers would
see each port/interface combination as a separate host and load balance
across the two, splitting the connection-handling CPU load fairly evenly
between the two CPUs.

Is this idea feasible? Is there a better way of solving this, without
cutting the number of LDAP operations being performed or throwing more
hardware at it?

Yes, it sounds like using a separate thread per listener would work for you. Obviously the code doesn't work this way at the moment, so you have a bit of hacking to do. I don't believe that the ultimate solution for slapd will use a dedicated thread per listener, since it requires a separate load balancer to make it viable, but certainly it would help your case.

 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support