Yahoo Groups archive

Milter-greylist

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

Message

Re: [milter-greylist] [Fwd: watch-greylist]

2006-08-02 by Chris Hoogendyk

Oliver Fromme wrote:
> Matthias Scheler wrote:
>  > Chris Hoogendyk wrote:
>  > > We are running milter-greylist-1.6 on Solaris 9 with Sendmail 8.13.6,
>  > > etc. on an E250 with dual sparc processors.
>  > > 
>  > > We didn't go to milter-greylist-2.0.2 when building the system, because
>  > > we experienced what appeared to be memory leaks when trying to run it.
>  > > These seem to be in 1.6, but seemed to be worse in 2.0.2.
>  > 
>  > Are you sure this is not a Solaris bug? Quoting from an e-mail which
>  > somebody sent to this list a while ago:
>  > 
>  > 	Ok, I found the problem. Milter-greylist is innocent. It's a Solaris 
>  > 	bug. Solaris 8 needs the 108827-40 patch (which has since then been 
>  > 	obsoleted by 108993-39). There seem to be severe leaks in
>  > 	getaddrinfo() and friends in non-patched libpthread/libsocket/libnsl.
>  > 
>  > Solaris 9 might require a similar patch.
>
> A friend of mine is running milter-greylist 2.1.3 on
> Solaris 9 without problems.  The process size grows at
> the beginning (which is normal because the greylist
> grows).  The growth slows down eventually (slowly).
> NB:  "uname" information from that machine, if it helps:
> SunOS 5.9 Generic_117171-02 sun4u sparc SUNW,UltraAX-i2
>   

That's a SunFire V120, which has a single sparc processor. *If* we are
talking about an issue that is related to not being thread safe, then it
might not have a problem on that machine. Do you know what volume of
mail they handle?

We saw that growth also when we tried 2.0.2. It seemed extreme and
counter to our experience running with the 1.6 version. Does that make
sense? Is there a significant difference in the way the two versions are
handling things?

> You should make sure that you are up-to-date with Sun's
> recommended patches, no matter what version of Solaris
> you're running.
>   
yup.

> I noticed that the memory handling (malloc()/free()) of
> milter-greylist is a pretty tough test for the system's
> malloc implementation.  Solaris, Linux and the BSDs all
> have very different implementations.  Some of them are
> optimized for speed, some for low memory consumption,
> and some try be good at both.  So if you think you see
> a memory leak, it might also be an artefact of your
> system's malloc implementation.  If your system's imple-
> mentation can be configured (such as FreeBSD's, see
> the malloc(3) manual page), you could give it a try to
> tune it better for milter-greylist.
>   

From the Solaris 9 man pages:

USAGE
     Portable applications should avoid using valloc() but should
     instead  use  malloc()  or  mmap(2). On systems with a large
     page size, the  number  of  successful  valloc()  operations
     might be 0.

     Comparative features of malloc(3C), bsdmalloc(3MALLOC),  and
     malloc(3MALLOC) are as follows:

        o  The bsdmalloc(3MALLOC) routines afford better  perfor-
           mance, but are space-inefficient.

        o  The malloc(3MALLOC) routines are space-efficient,  but
           have slower performance.

        o  The standard, fully SCD-compliant malloc routines  are
           a trade-off between performance and space-efficiency.


---------------

Chris Hoogendyk

-
   O__  ---- Systems Administrator
  c/ /'_ --- Biology & Geology Departments
 (*) \(*) -- 140 Morrill Science Center
~~~~~~~~~~ - University of Massachusetts, Amherst 

<hoogendyk@...>

--------------- 

Erd\ufffds 4

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.