On Nov 5, 2009, at 3:05 PM, John Haxby wrote:
2009/11/5 Jan-Frode Myklebust <[email protected]>
Looks like it was flooded with connections from one machine, enough to
eat up all the 8192 fds configured. Fair enough, but the problem was
that while this was happening the clients were not failing over to the
other ldap server, they seemed stuck on sim2.example.net. As soon as
we shut down sim2.example.net, the clients moved to sim1.
So, is there any way to avoid this tarpit ? Somehow make the clients
more eager to switch ldap server when it becomes unresponsive?
I think it's worth running nscd on the various client machines as
well: this will dramatically cut the amount of traffic to the ldap
servers and should stop them getting overloaded.
Assuming that the directory can be configured that way, you could
also increase the maximum number of connections. (I know that the
389 directory can be configured that way because when I start mine
up it moans that it can only accept about 1000 concurrent
connections.)
nscd is a must in any real large LDAP environment. We have run into a
similar problem when OpenLDAP ran out of file descriptors because what
happens is that (correctly) a client instantiates a new connection and
OpenLDAP needs to get a new file descriptor the client then has to
wait for the server to have one (which of course it never does because
of long running LDAP connections). PADL (nss_ldap) thinks this is a
real connection and doesn't fail over to the later servers in your list.
Derek Yarnell
UNIX Systems Administrator
University of Maryland
Institute for Advanced Computer Studies
_______________________________________________
rhelv5-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/rhelv5-list
