Milter-greylist

Well, I only hope there is no reason for milter-greylist to allocate
8192Kb stack size, right?
Both greylist and whitelist databases are in the main memory.

Ondrej

Johann E. Klasek wrote:
>
> 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.
>
>