[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: broken pipe - serious problem with OpenLDAP 2.0.21
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