Yahoo Groups archive

Milter-greylist

Index last updated: 2026-04-28 23:32 UTC

Message

Re: [milter-greylist] memory consumption

2010-02-16 by Oliver Fromme

Peter Bonivart wrote:
 > Dietmar Rieder wrote:
 > > we are running milter-greylist-4.2.3 on Solaris 10 x86, it works great
 > > so far, but I'm a little concerned by its memory consumption. Right
 > > after starting the service it uses < 30Mb of RAM but after running it
 > > about 48h it uses already ~1Gb of RAM.
 > > 
 > > Is this normal?
 > > Is there something that could be done to limit the memory consumption?
 > 
 > I package miltergreylist for www.opencsw.org and it's "normal" that it
 > leaks memory. I use a restart script to keep it in check.
 > 
 > With commands like "pmap -x <miltergreylist-pid>" you can see how much
 > memory it's consuming. From there you can easily build a script to
 > restart it before it goes to insane values.
 > 
 > Funny thing is that some Linux users (including myself) have no issues
 > with this on miltergreylist but with ClamAV it's the other way round,
 > ClamAV seems to leek more memory on Linux than on Solaris.

It's not necessarily milter-greylist (or clamav) that leaks
memory.  It could be a matter of the malloc implementation
in libc on the respective systems.

The malloc implementations are usually optimized for "typical"
allocation patterns, but sometimes there are programs that
use memory allocations in different patterns which leads to
fragmentation and inefficient use of actual memory.  Threaded
programs seem to be especially prone to this kind of problem.

On FreeBSD, the allocation algorithm can be tuned with about
a dozen knobs (globally via /etc/malloc.conf, or per-process
via environment variables).  This is sometimes worthwhile if
a program seems to leak memory.  I don't know if Solaris has
something similar, but it might be worth investigating.

By the way, on my FreeBSD machines milter-greylist doesn't
leak.  It grows up to a certain size and then stabilizes,
depending on the amount of mail traffic.  (I could probably
shrink that size down somewhat via malloc.conf, but I didn't
bother so far because there's enough memory available.)

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

We're sysadmins.  To us, data is a protocol-overhead.

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.