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-19 by Ondrej Valousek

Hi Johann,

Ok I see the point.
I was trying to figure out how much memory is the milter-greylist using
on my system using the top command and I am not sure whether it gives me
the accurate results.
Do I have the feed top command with some additional switches to find out
the total amount of resources it consumes?

I am just trying to find out why it has died last time - was it just a
lack of system resources, not enough file descriptors or broken spf
library (saw the last discussion).
At the moment I have nothing to start with.
Maybe I could enable the verbose logging or enable core files (not sure
what is the best).

So far, this software just rocks and from what I have seen, it is also
well written (every memory allocation is checked, bullet-proof code,
pity it is not C++...) so there must be some ways to find out more. I
would like to keep using it.

Ondrej

Johann E. Klasek wrote:
>
> On Tue, Mar 18, 2008 at 11:04:55AM +0100, Ondrej Valousek wrote:
> > Well, I only hope there is no reason for milter-greylist to allocate
> > 8192Kb stack size, right?
>
> Not really ;)
> Just to point out:
> It is not the matter of allocating, the stack area is reserved by the
> thread library, no matter if the threaded code is using it or not.
> Anyway, the address space for the reserved stack area is consumed, no
> matter how the stack is filled. Each thread instance in a process
> context needs (gets) this space sharing all the same (virtual) memory
> address space (which is limited depending on the address architecture of
> the OS).
>
> > Both greylist and whitelist databases are in the main memory.
>
> What is main memory? What you probably want to say is, that the DB
> resides on the heap of the process (virtual) memory space. Actually, the
> stack area for each newly started thread is also taken from this process
> heap ...
>
> However, in virtual memory context, the address space (per process) is
> limited anyway to the range an 32-bit addresses could reach.
>
> 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.