Large mail queues

[Patterson, S R]

The second sendmail to process local mail is a good idea as it stops
the delivery runs being held up by a poorly responsive remote server
timeout.  Then that's not a problem if you deliver in the background
and set your batch size to 1 anyway ... :)

--
Steven Patterson, MSci ----------------------------------------------+
|       Electronic Information Systems Support and Development       |
|         Computing Services, University of Southampton, UK.         |
+-------------------------------------------- Tel: +44 (0) 2380 595810
......                                                          ......
..       Conviction is a bigger enemy of the truth than lies.       ..
......                                                          ......


> -----Original Message-----
> From: Julian Field [mailto:jkf at ECS.SOTON.AC.UK]
> Sent: 01 February 2002 14:08
> To: MAILSCANNER at JISCMAIL.AC.UK
> Subject: Re: Large mail queues
>
>
> Have you tried switching off spam detection, or using "Delivery in
> Background = yes".
> The sleep(30) is only used when there is very little/no
> incoming mail anyway.
>
> Perhaps other people with large throughput might like to comment?
> (I don't like the "-q1m" solution at all, it was suggested by
> someone else).
>
> At 11:55 01/02/2002, you wrote:
> >However we did have a few problems initially with very large
> mail queues
> >building up when we went live. (From our usual number of
> about 600 to 15500)
> >
> >We did several things to improve matters and thought these
> might be of
> >interest to others in similar situations.
> >
> >1. Changed the sleep(30) to sleep(2) (the delay time between
> mailscanner
> >selecting the next batch to process) in mailscanner. We were
> finding the
> >incoming mail building up faster than mailscanner could cope
> because of this
> >delay. It would be nice if this were a configurable parameter.
> >
> >2. Once the queues had built up to this size things
> deteriorated further
> >because of problems unix has with large directory sizes, and
> this slowed
> >down mailscanner's ability to process the queue so we
> recreated the queues
> >from scratch and started afresh.
> >
> >3. Sendmail change - this was not really anything to do with
> mailscanner,
> >but it helped the faster delivery of local mail. We started
> an additional
> >sendmail process for the output queue with parameter of
> -qRkcl (where kcl is
> >our local domain) to process local mail.
> >
> >4.  The -q1m parameter on sendmail was used (as suggested in
> the FAQ).
>
> --
> Julian Field                Teaching Systems Manager
> jkf at ecs.soton.ac.uk         Dept. of Electronics & Computer Science
> Tel. 023 8059 2817          University of Southampton
>                              Southampton SO17 1BJ
>