[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: performance issue behind a a load balancer 2.3.32
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
--
John Morrissey _o /\ ---- __o
jwm@horde.net _-< \_ / \ ---- < \,
www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__