John Morrissey wrote:
Yes, this is definitely a bottleneck. The IBM folks are currently experimenting with different approaches to improve the situation.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, 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.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?
-- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support