We are currently running 2.3.32, we can't upgrade to 2.4 yet as we are using slurpd. (yes, we are behind the times...) Are those two bugs ITS#3850 and #6189 fixed in the latest 2.3.x release?
-- David J. Andruczyk
----- Original Message ---- From: John Morrissey jwm@horde.net To: David J. Andruczyk djandruczyk@yahoo.com Cc: openldap-software@openldap.org Sent: Thursday, July 30, 2009 9:33:34 AM Subject: Re: performance issue behind a a load balancer 2.3.32
On Thu, Jul 30, 2009 at 05:34:39AM -0700, David J. Andruczyk wrote:
Mgmt is of the mindset, of "if it works (even if it doesn't provide proper redundancy right now), then leave it be", which is OK, if servers never ever crash. I'm of the opinion of finding out WHY the ldap servers log "connection deferred: binding" when behind the F5's and ONLY when past a certain arbritrary load threshold.
nod, a good attitude to take. Especially because at some point, you're going to have an outage that round-robin DNS can't handle and your management is going to come to you asking why that traffic isn't load balanced. ^_____^
hence my focus on conn_max_pending, and conn_max_pending_auth. thought I haven't heard a concrete response yet, saying that, "Yes,in your case where al lthe traffic will appear to come from the F5, due to the network layout, those parameters are too low and likely to throttle connections at some arbritrary level.".
At least two people (Philip and Howard) have said the exact opposite: conn_max_pending{,_auth} are not going to have any effect on this situation. These directives control the number of pending operations *for each connection*.
In your case, yes, slapd sees all connections as originating from your BigIPs. Unless the BigIP is doing some deep magic LDAP connection pooling, there are numerous connections open, one for each LDAP client connection. These directives are per-connection and *do not* apply to the total number of operations pending across all connections.
More importantly, the error message you're getting indicates that increasing these values will have no effect. The problem is that slapd is receiving another LDAP operation on a given connection while a bind operation is still being processed for that connection. As Philip said, this is a violation of RFC 4511 and slapd correctly rejects it.
The behavior you're seeing could also be the result of software bugs in slapd that have since been fixed. Have you made sure your OpenLDAP build is more recent than/patched for ITS#3850 and #6189, as Howard mentioned?
john