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

Re: Memory

> Pierangelo Masarati ÐÉÛÅÔ:
>
>> Fyodor Smirnov wrote:
>>
>>> What can I do to solve this problem?
>>
>> run slapd under valgrind or any other leak detector for a few seconds
>> (loading it with the typical operations your server is loaded with),
>> then stop it and see what does it say about memory leaks.
>
> For a few seconds only?

I should have stated "long enough to see any significant traffic"

> I use slapd for storing user mail database and for checking presense and
> parameters of mailboxes in database by mail server.
> Now this server receives about 400 messages per hour (about only 1
> message per 9 seconds).

In this case, let's say few minutes.

> SMTP server uses EXTERNAL authentication and
> does 2 requests (mailbox presence, mail filter parameter check) to slapd
> for each recipient address by proxy authorization.
> Load on server is constant and does not significantly changes in time, but
>
> when I start slapd, I see (top command):
> PID USERNAME  THR PRI NICE   SIZE    RES STATE    TIME   WCPU COMMAND
> 16841 ldap        3  20    0 10768K  6140K kserel   0:00  0.00% slapd
>
> after 1 minute:
> 16841 ldap        3  20    0 21268K  6356K kserel   0:00  0.00% slapd
>
> after 30 minutes:
> 16841 ldap        3  20    0 83720K  7160K kserel   0:03  0.00% slapd
>
> after 10 hours (night):
> 16841 ldap        3  20    0   173M  8616K kserel   2:06  0.00% slapd
>
> Is this normal behavior?

Yes and no.  The process may grow since it's going to cache stuff and so
on.  No if that growth corresponds to memory leaks.  But this is general,
of course, not OpenLDAP specific.

> Valgrind output after ~3 hours:
> =======================================================
> ==12192== Memcheck, a memory error detector for x86-linux.
> ==12192== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward.
> ==12192== Using valgrind-2.1.0, a program supervision framework for
> x86-linux.
> ==12192== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward.
> ==12192==
> ==12192== My PID = 12192, parent PID = 12148.  Prog and args are:
> ==12192==    /usr/local/libexec/slapd
> ==12192==    -h
> ==12192==    ldapi://%2fvar%2frun%2fopenldap%2fldapi/ ldap://0.0.0.0/
> ==12192==    -g
> ==12192==    ldap
> ==12192==    -u
> ==12192==    ldap
> ==12192==    -d
> ==12192==    256
> ==12192== Estimated CPU clock rate is 1822 MHz
> ==12192== For more details, rerun with: -v
> ==12192==
> ==12192== warning: Valgrind's pthread_attr_destroy does nothing
> ==12192==          your program may misbehave as a result
> ==12192== warning: Valgrind's pthread_attr_destroy does nothing
> ==12192==          your program may misbehave as a result
> ==12192== warning: Valgrind's pthread_attr_destroy does nothing
> ==12192==          your program may misbehave as a result
> ==12192== warning: Valgrind's pthread_cond_destroy is incomplete
> ==12192==          (it doesn't check if the cond is waited on)
> ==12192==          your program may misbehave as a result
> ==12192== warning: Valgrind's pthread_cond_destroy is incomplete
> ==12192==          (it doesn't check if the cond is waited on)
> ==12192==          your program may misbehave as a result
> ==12192== warning: Valgrind's pthread_cond_destroy is incomplete
> ==12192==          (it doesn't check if the cond is waited on)
> ==12192==          your program may misbehave as a result
> ==12192==
> ==12192== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
> ==12192== malloc/free: in use at exit: 13656 bytes in 93 blocks.
> ==12192== malloc/free: 153101 allocs, 153008 frees, 107445958 bytes
> allocated.
> ==12192== For counts of detected errors, rerun with: -v
> ==12192== searching for pointers to 93 not-freed blocks.
> ==12192== checked 5220180 bytes.
> ==12192==
> ==12192== 49 bytes in 5 blocks are definitely lost in loss record 3 of 17
> ==12192==    at 0x3C032183: malloc (in
> /usr/local/lib/valgrind/vgpreload_memcheck.so)
> ==12192==    by 0x3C36078B: strdup (in /lib/libc.so.6)
> ==12192==    by 0x3C35B54E: _nsyylex (in /lib/libc.so.6)
> ==12192==    by 0x3C35A9D4: _nsyyparse (in /lib/libc.so.6)
> ==12192==
> ==12192==
> ==12192== 224 bytes in 3 blocks are definitely lost in loss record 5 of 17
> ==12192==    at 0x3C032183: malloc (in
> /usr/local/lib/valgrind/vgpreload_memcheck.so)
> ==12192==    by 0x3C2B48D0: (within
> /usr/local/lib/valgrind/libpthread.so.2)
> ==12192==    by 0x3C2B5F49: pthread_mutex_init (in
> /usr/local/lib/valgrind/libpthread.so.2)
> ==12192==    by 0x3C041DBC: ldap_pvt_thread_mutex_init (in
> /usr/local/lib/libldap_r-2.3.so.2)
> ==12192==
> ==12192== LEAK SUMMARY:
> ==12192==    definitely lost: 273 bytes in 8 blocks.
> ==12192==    possibly lost:   0 bytes in 0 blocks.
> ==12192==    still reachable: 13383 bytes in 85 blocks.
> ==12192==         suppressed: 0 bytes in 0 blocks.
> ==12192== Reachable blocks (those to which a pointer was found) are not
> shown.

What I see here is that only 273 bytes have been definitely leaked.  Of
those, the first report does not belong to OpenLDAP, as far asI can tell:
it's related to strdup in _nsyyparse(), and from the function's name it
looks like something generated by yacc (a parser) and should be a one-time
leak, i.e. related to parsing a configuration.  The second one does belong
to OpenLDAP (I'm pretty sure this has been fixed in HEAD, and might in
re23 as well), and it definitely looks like a one-time leak as well: a
mutex is initialized and never destroyed.  Either the rest of the size
growth couldn't be detected by valgrind or it was desired, i.e. resources
were released at shutdown.

Of course, I assume you used --trace-children=yes, otherwise you wouldn't
see what slapd's threads might have leaked.  Here's the command line I
usually use for slapd:

valgrind --tool=memcheck \
 --trace-children=yes --leak-check=full \
 --show-reachable=yes --num-callers=20

p.



Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office:   +39.02.23998309
Mobile:   +39.333.4963172
Email:    pierangelo.masarati@sys-net.it
------------------------------------------