Yahoo Groups archive

Milter-greylist

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

Message

Re: [milter-greylist] Re: termination after rcpt flood

2008-03-18 by Johann E. Klasek

On Sat, Mar 15, 2008 at 07:46:45PM -0000, netbrain2003 wrote:
> I have no special limits adjusted and I can not imagine the daemon
> itself is running out of resources. Anyway that are the system
> defaults, I don't know the software needs, perhaps you see a bottleneck:
> 
> $: ulimit -a                                                         
>                                            
> -t: cpu time (seconds)         unlimited
> -f: file size (blocks)         unlimited
> -d: data seg size (kbytes)     unlimited
> -s: stack size (kbytes)        8192

Depending on which OS you have, memory consumption in due to multi-
threading can be considerably. E.g. Multithreading libraries in current
Linux distributions allocates stacksize for *each* thread that memory
every new process usually gets. Calculating this with your stacksize
above, 8192 kbytes and assuming a 32bit system which is usally limited
to say 2 GByte (virtual) address space then just around 256 threads
working in the milter-greylist process are filling up the address space.
In addition, milter-greylist needs a plenty of memory for its greylist
DB too, which resides in the same address space and is not counted so
far.

At our site we have an average of 128 current milter-greylist threads
(ps -eL|grep milter-greylist). In heavy times 256 and more are easily
reached. We are facing this situation by reducing the stacksize to 256K
even we are on a 64bit system (with larger address space, but only if
the application was compiled for 64bit). Sometimes I encountered
packages (e.g. amavis-milter or other thread-based things) which were
architecture independent but alas, they have the usual 32bit limits ...

> -c: core file size (blocks)    0
> -m: resident set size (kbytes) unlimited
> -u: processes                  8063
> -n: file descriptors           1024

As Manu already mentioned, the maximum descriptor cound should be raised
too.


Johann K.

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.