Milter-greylist

Michael Fromme wrote:
 > Sorry to say, but 4.0a4 still leaks memory with our configuration.

How do you determine that?

It is quite normal that the milter-greylist process grows.
The more SMTP connections you get, the more tuples it has
to store in memory.  The old tuples are not always
immediately freed when they expire, but they're only
garbage-collected when they are encountered during
traversing the list.  Emmanuel has explained that several
times in the past.

How much memory (or rather VM pages, to be exact) are used
also depends a lot on the malloc() implementation of the
libc of your operating system (for those who are not
familiar with C programming:  malloc() is the standard
C library call used to allocate memory for a process).

milter-greylist uses a lot of malloc() and free(), which
can lead to fragmentation, and some operating systems can
handle that better than others.  Often it is a trade-off
between memory efficiency and speed.  There are even malloc
implementations that never return unused VM pages back to
the kernel (except on process termination, of course).

Just as an example, on FreeBSD you can configure various
options for malloc() via /etc/malloc.conf.  For example,
by enabling the "R" flag, fragmentation can be reduced for
better memory efficiency, at the cost of speed, and there
are other flags to influence the behaviour.  Other
operating systems might have different ways to configure
malloc() behaviour, or possibly use a different libc with
a different implementation.

 > My question to other users: Do they observe this, too?

I don't observe any unusual behaviour that could only be
explained by a leak in milter-greylist.  Of course, the
process grows with time, but I think that's normal.  It
also starts to shrink somehwat when there are days with
lower number of SMTP connections.

Note that I'm not saying that there is no leak.  I'm just
saying that I don't have any hard evidence for that.

By the way, I see an interesting behaviour of the local
DNS server process (BIND) which seems to "follow" the
milter-greylist process.  When there is high activity
and milter-greylist grows, the named process also grows
somewhat.  I guess that's because sendmail and/or milter-
greylist perform DNS lookups for all the hosts which
connect (most of them are trying to deliver spam, of
course), and BIND caches them in memory for some time.
I'm not worried about that either, and I don't think
that BIND has a serious leak.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch\ufffdftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M\ufffdn-
chen, HRB 125758,  Gesch\ufffdftsf\ufffdhrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"When your hammer is C++, everything begins to look like a thumb."
        -- Steve Haflich, in comp.lang.c++