[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
memory leak, or "normal" behaviour?
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.
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.)
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?
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?
Denis
T-Mobile Austria GmbH,
Information Technologies / Services
Knowledge Management & Process Automation
Dr. Denis Havlik, eMail: denis.havlik@t-mobile.at
Rennweg 12, Zi. 444 Phone: +43-1-79-585/6237
A-1030 Vienna Fax: +43-1-795-85/6584