Re: memory leak, or 'normal' behaviour?

["Pierangelo Masarati" <ando@sys-net.it>]

> Hi, everyone
>
> I've been testing my installation (openldap v. 2.1.25) lately, and run
> into something that looks like a memory leak to me. What I did is rather
>  simple:
>
> 1) run { for (( i=0; i<2000; i++ )) ; do { sleep 1; time -f "%E"
> ldapwhoami &} ;  done; }
> 2) watch the "top" output on server, sorted by memory usage.
>
> This was primarly intended as a prood of the memory leak that is
> supposed  to exist when openldap is compiled against MIT kerberos, and
> SASL/GSSAPI  authentication is used, and the first part of the test
> looked as if the  problem were confirmed.
> That is, memory usage of slapd (as shown by top) grows continuusly with
> every new SASL/GSSAPI bind
>
>                 VIRT    RES     SHR
> test start      4836    4828    3384
> +2000 binds:    5020    5012    3392
>
> Morover, a sleep of 0.1s already kills the slapd, which is definitively
> not nice.

can you provide a stack trace?  It would be nice if you open an ITS about
this, with all the information you can gather on this problem.

>
> Stupid part is that I get a similar growth in the slapd size with simple
>  bind as well, which makes the test completely useless:
>
>                 VIRT    RES     SHR
> slapd restart   3308    3300    2540
> +2000 binds     4292    4284    3028
> +2000 binds     4432    4424    3028
>
> Good news is that simple bind does not kill slapd, and that the growth
> isn't very steep (restarting slapd once/day should be enough to keep the
>  system running fine in my environment), but I still find this memory
> footprint growth ugly.
>
> QUESTIONS:
>
> 1) Am I the only one experiencing this? (Could someone pls. test at his
> site.)

well, I can't answer this in a complete manner.  I guess at the beginning
some growth is physiological, especially if more threads are being opened;
after a bit there shouldn't be any, at least steady.  Temporary growth and
shrinkages should be natural, since slapd makes an extensive use of heap.

> 2) Is this considered a bug, or is a "normal" behaviour for openldap? 3)
> In case of a bug, has this been fixed in some later version of
> openldap?

A bug.

> 3) In case this is "normal", is there an upper limit on memory footprint
>  growth, or is it going to continue growing until big bang?

I think big-bang would be the natural evolution.

Please file an ITS, especially if you can provide a more specific
description of the problem localization (e.g. if you can analyze it with
any memory leak tracer).

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it