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.
Message
Re: [milter-greylist] Re: termination after rcpt flood
2008-03-18 by Johann E. Klasek
Attachments
- No local attachments were found for this message.