[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: broken pipe - serious problem with OpenLDAP 2.0.21



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