[Date Prev][Date Next]
Re: Connection-handling threads
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
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
Symas: Premier OpenSource Development and Support