Re: (ITS#4387) slapd-ldap backend leaks descriptors on closed connections on x86_64

[aleksander.adamowski@gmail.com]

On 2/4/06, Pierangelo Masarati <ando@sys-net.it> wrote:
> On Fri, 2006-02-03 at 21:55 +0000, aleksander.adamowski@gmail.com wrote:
> > However, do you think that it's correct for slapd-ldap backend to do
> > the following:
> > 1) Not get rid of descriptors for connections closed by the other side
> > (CLOSE_WAIT state)
> > 2) Not reuse cached connections queries, but open more and more new connections?
> >
> > In my opinion this behaviour is not correct.
>
> I haven't noticed the behavior you describe; I don't understand how it
> could happen (and I'm not 100% sure I understood what's actually
> happening; that's why I didn't answer this point).
>
> A new connection between proxy and remote server is established when no
> appropriate cached connection exists or when a bind occurs on an
> existing cached connection.

This would explain lack of connection reuse to some extent....

Almost all connections come from the Courier MTA - its authldap and
ldapalias daemons.

They bind as the user cn=Courier,o=...etc..., so practically 98% of
connections are associated with a bind operation.

>  Cached connections are closed when the
> client disconnect, except for the anonymous connection which remains
> open and is shared by all anonymous clients.

It seems that in this case cached connections weren't being closed
after client disconnection.
That's because I'm almost certain that the clients didn't open as much
simultaneous connections to slapd-ldap backend, as the slapd-ldap
backend was opening to the slapd-bdb backend.
First of all, the sum of limits on process count for ldapalias daemon
and authdaemon was much lower (max. 24 and 28 processes,
respectively). Those daemons don't open more than a single connection
per process AFAIK. So the whole Courier server shouldn't open more
than 52 connections to LDAP.

There are some application on our network that connect to LDAP
independently, but I'd estimate that they together open at most 20
simultaneous connections (during peak hours).

So there definately weren't more that 100 client simultaneous
connections to the server, while slapd-ldap has managed to open over
1024 connections to the backend.

Seems like there were lots of unnecessary connections that slapd-ldap
had kept without a cause.

> Establishing a new connection when a bind occurs was a recent change
> (ITS#4315, I believe); this might be causing resource "leaking" (not
> really a leak; see below), because the existing cached connection is
> ignored, and a new one is created.
>
> This is not actually a leak because the connection remains accessible in
> the connection tree, but it might not be intercepted by the
> connection_destroy() hook; so it's only destroyed when the connection
> tree is freed, i.e. at shutdown.  This is a guess, I haven't
> investigated the issue deep enough yet.

This would go along with my observations - connections from slapd-ldap
to slapd-bdb were not destroyed; most of connections to slapd-ldap
(and the resulting connections from slapd-ldap to slapd-bdb) weren't
anonymous.

Best Regards,
--
    Aleksander Adamowski
        Jabber JID: olo@jabber.altkom.pl
        GG#: 274614
        ICQ UIN: 19780575
        http://olo.ab.altkom.pl