Good ideas. At present, ldap restarts every hour anyway. I've found the problem, though and it's not with OpenLDAP per se and not with the clients. The problem is the shear number of connections. Once they bring the total connections to ldap up to 1024, connections start dropping. To solve this, I added an idletimeout to slapd. Right now I'm playing around with 30 seconds. That's worked really well, except the WAITING connections (ended connections) is climbing slowly. Should be okay for now. Each of the clients that runs anything that uses getpwnam creates a connection. The problem is that a typical gnome session creates 10 or 15 connections! nscd may help alleviate this. Anyway, if others have this problem, this is something to check out. Michael On Thu, 2002-04-18 at 00:38, Jan-Michael Ong wrote: > I dont't know wheteher this feature is availablae with openldap as well, but > with other ldap server you can tune on the connection idle time. > > >> I think you can use idletimeout (check slapd.conf) but I'm not sure if this > does the trick > > Closing your connections does help as I've experienced this type of a variation > of this problem on Openldap 1.2.x, 2.0.7 and more recently 2.0.18... it > definitely has something to do with running out of file descriptors (at least my > experience has been this .. though I don't get the broken pipe error that you > get). Of course I'm running it on Solaris if that makes a difference. > > I've considered load-balancing the ldap servers so as to not put so much load on > it but I'm running into some ldap-server behind the firewall and referral issues > (I've posted a note on this forum about 4 days ago but alas no one has had a > chance to respond yet) > > You may just consider restarting your slapd every so often. At least, you can > run a perl script to detect ldap activity and to restart it if your response > time falls below your expected "processing" time. > > I'm not sure if this is what you're looking for but I hope that helps. > > JM > > "Smits.Dolf" wrote: > > > Hi, > > > > I dont't know wheteher this feature is availablae with openldap as well, but > > with other ldap server you can tune on the connection idle time. > > > > If such a parameter is available, you migth lower it to keep the number of > > connections to a reasonable number. > > > > (or do it the hard way and find in the source where this is specified, and > > tune it there and recompile) > > > > Just my idea's :-) > > > > Dolf Smits > > > > -----Original Message----- > > From: Michael Torrie [mailto:torriem@cs.byu.edu] > > Sent: donderdag 18 april 2002 1:30 > > To: openldap-software@OpenLDAP.org > > Subject: Re: broken pipe - serious problem with OpenLDAP 2.0.21 > > > > To follow up, I stopped one script that was doing ldap stuff every > > couple of minutes. This started to reduce the number of "WAITING" > > sockets down to reasonable numbers (These typically climbed up into the > > 100s of sockets). > > > > Now I still see many connections that are in "WAIT" I think from pam or > > nss_switch stuff. So I'll communicate with those guys and see if > > there's a known issue. > > > > Michael > > > > On Wed, 2002-04-17 at 15:46, Michael Torrie wrote: > > > On Wed, 2002-04-17 at 11:43, Chris Garrigues wrote: > > > > > > > > I had a similar problem which went away when after I went through all my > > perl > > > > scripts that used perl-ldap and made sure that they properly closed > > their > > > > connections to the LDAP server before they ended. Once I stopped > > leaving stray > > > > connections to the server all over the place, things got *much* better, > > and I > > > > haven't seen a problem since. > > > > > > I think you might be on to something. That very well could be the > > > reason for the troubles. Next time we experience the "crash" I'll check > > > the netstats and see how many connections are open. I'm thinking you > > > are right. Thanks for the insight. > > > > > > Michael > > > > > > > > > > > > > > Chris > > > > > > > > -- > > > > Chris Garrigues http://www.DeepEddy.Com/~cwg/ > > > > virCIO http://www.virCIO.Com > > > > 716 Congress, Suite 200 > > > > Austin, TX 78701 +1 512 374 0500 > > > > > > > > My email address is an experiment in SPAM elimination. For an > > > > explanation of what we're doing, see http://www.DeepEddy.Com/tms.html > > > > > > > > The Greatest tragedy in mankind's entire history may be the > > > > hijacking of morality by religion. However valuable -- even > > > > necessary -- that may have been in enforcing good behavior on > > > > primitive peoples, their association is now counterproductive. > > > > Yet at the very moment when they should be decoupled, > > > > sanctimonious nitwits are calling for a return to morals based > > > > on superstition. > > > > --- Arthur C. Clarke > > > > > > > > > > > -- > > > Public key available from http://students.cs.byu.edu/~torriem > > > > > > > > -- > > Public key available from http://students.cs.byu.edu/~torriem -- Public key available from http://students.cs.byu.edu/~torriem
Attachment:
signature.asc
Description: This is a digitally signed message part