Preference for batch sizes

Ken Anderson ka at PACIFIC.NET
Fri Feb 13 23:05:05 GMT 2004


It depends on how much mail you are processing too. Setting only 3 MS
children and 10msg per batch may be fine for <50 msgs/minute, but will
quickly fall behind if you are receiving 500 msgs/minute. You'll need
more children, bigger batches, and an additional server.

Ken A
Pacific.Net


Steve Campbell wrote:

> Mr. Hooton,
>
> Thank you for a very informative response. I am seeing some really strange
> things happening here, as I have alluded to in prior post with this subject. I
> will more than likely have to start using tempfs for some things, but first I
> will break up our domains across multiple boxes.
>
> The strangeness of no timeouts for RBL and SA as a general rule, small amounts
> of mail in incoming taking a very long time to clear, and the load average
> dropping regardless of what is in either queues has me baffled. Especially,
> since before Tuesday night, large amounts of email being dumped into this
> server was handled very swiftly. Load average usually remained proportionate
> to emails waiting to be scanned or delivered.
>
> One other thing I am going to do is wean myself away from linuxconf and begin
> using sendmail to it's fullest. (Be warned - Another post coming to either
> this list or some other). I really have a problem with non-existent user
> email. I feel it's a shame to waste resources just to eliminate bounces, but I
> have yet to find how these are resolved by Sendmail.
>
> Thanks very much
>
> Steve Campbell
>
>
> Quoting David Hooton <david at PLATFORMHOSTING.COM>:
>
>
>>>-----Original Message-----
>>>From: MailScanner mailing list [mailto:MAILSCANNER at JISCMAIL.AC.UK] On
>>>Behalf Of Stephe Campbell
>>>Sent: Friday, 13 February 2004 3:55 AM
>>>To: MAILSCANNER at JISCMAIL.AC.UK
>>>Subject: Re: Preference for batch sizes
>>>
>>>I do not use Razor, but the suggestion to lower the message count per scan
>>>seemed to fix it up. I am not running at 2 or 3 messages in my incoming.
>>>Somehow, I missed the prior thread.
>>>
>>
>>
>>Hi Steve,
>>
>>I've found on an i386 box with 1 gig of ram, 80 Gig 7200RPM IDE disk and an
>>AMD 2200 processor, using tempfs for the work dir that 3 children and 10
>>messages per batch is the most efficient combination.
>>
>>If you have an evening free, write yourself a script to flood the box with a
>>decent number of messages and do some timings on how long each combination
>>takes to clear the queue - results below.
>>
>>Spam Load Test
>>
>>Messages        Children        Msg/batch       Mins
>>50              4               5               0:08:39 Workdir = DISK
>>50              3               5               0:08:05 Workdir = DISK
>>50              3               10              0:09:38 Workdir = DISK
>>50              2               10              0:13:07 Workdir = DISK
>>50              1               10              0:17:00 Workdir = DISK
>>50              0               10              0:15:00 Workdir = DISK
>>50              3               5               0:01:51 Workdir = TEMPFS
>>50              3               10              0:01:02 Workdir = TEMPFS
>>50              3               15              0:01:10 Workdir = TEMPFS
>>
>>We've managed to drop load on the box to 1/3 of it's old load just by
>>playing with these settings alone, and a further reduction in load after
>>that by tuning our spamassassin rules very savagely.
>>
>>We have also recently taken to storing the Bayes DB's in tempfs which has
>>helped further reduce load and improve performance.
>>
>>Hope this helps you and anyone else with these kinds of issues.
>>
>>Cheers!
>>
>>Dave
>>
>>
>>========================================================================
>> Pain free spam & virus protection by:          www.mailsecurity.net.au
>> Forward undetected SPAM to:                   spam at mailsecurity.net.au
>>========================================================================
>>
>
>
>
>
>
> -------------------------------------------------
> This mail sent through IMP: http://horde.org/imp/
>
>



More information about the MailScanner mailing list