Re: [exim] Should queue processing be rewritten in Exim?

Top Pagina
Delete this message
Reply to this message
Auteur: Martin.Hepworth
Datum:  
Aan: exim-user
Onderwerp: Re: [exim] Should queue processing be rewritten in Exim?
So what's the underlying disk subsystem for the queue then? Hopefully you've some super-duper RAID10 or something with a 1/2 decent filesystem there?

What about round-robin DNS for load balancing across many incoming machine?

--
Martin Hepworth
Snr Systems Administrator
Solid State Logic
Tel: +44 (0)1865 842300

> -----Original Message-----
> From: exim-users-bounces@???
> [mailto:exim-users-bounces@exim.org] On Behalf Of Marc Perkel
> Sent: 02 July 2008 17:34
> To: exim-user
> Subject: Re: [exim] Should queue processing be rewritten in Exim?
>
>
>
> Peter Bowyer wrote:
> > On 02/07/2008, Marc Perkel <marc@???> wrote:
> >
> >> Suppose Exim had 2 queues instead of one. We'll call the
> first queue
> >> the primary queue which is a ram drive and the secondary
> queue which
> >> is a disk drive. All this is of course optional and user settable.
> >>
> >
> > You're proposing a solution before defining the
> requirements. What's
> > the high-level use case here?
> >
> > Peter
> >
> >
> Hi Peter,
>
> I'll use myself as an example. I am in the front end spam
> filtering business. (http://www.junkemailfilter.com) I have
> about 4000 domains pointed to a single Exim server. Email
> comes in - I filter it - and I send the good email on to the
> customer's existing server. This machine is running Exim
> only. Spamassassin is running on a several other computers as
> well as MySQL and caching DNS servers. This one box, which is
> the box most everything hits first is all Exim. I have
> several other Exim servers on the next level of MX for backup
> and overload handling.
>
> Additionally I have a a spam out channel where spam is
> forwarded to another server and is delivered to several other
> places that process my spam. It goes off to spam blocking
> companies for mining and to URIBL list processors to feed
> their block lists. These messages are very low priority and
> if they are lost or rejected there is no loss.
>
>
> Most email hits this server and if it's good is instantly
> relayed to the customer's server for delivery. Most spam is
> forwarded to my spam processing server and if it fails it's
> deleted. No retry on spam. If the customer's server is down
> or overloaded and I get a 4xx error on delivery the message
> is transferred to a retry server which will attempt to
> deliver the message for 4 days. So the idea of this main exim
> server is not to hold anything in it's own queue. Whatever
> comes in goes somewhere because it is the fast bulk processor.
>
> The bottleneck is the queue and I've noticed that if I use a
> ram disk for the queue that I can process many times as much
> mail with var lower load levels that using disk based queue.
> Ideally if I had a battery back up ram disk card that would
> be ideal but I can't find that anywhere.
>
> So - that's the problem I wish to solve.
>
>
> --
> ## List details at http://lists.exim.org/mailman/listinfo/exim-users
> ## Exim details at http://www.exim.org/
> ## Please use the Wiki with this list - http://wiki.exim.org/
>





**********************************************************************
Confidentiality : This e-mail and any attachments are intended for the
addressee only and may be confidential. If they come to you in error
you must take no action based on them, nor must you copy or show them
to anyone. Please advise the sender by replying to this e-mail
immediately and then delete the original from your computer.
Opinion : Any opinions expressed in this e-mail are entirely those of
the author and unless specifically stated to the contrary, are not
necessarily those of the author's employer.
Security Warning : Internet e-mail is not necessarily a secure
communications medium and can be subject to data corruption. We advise
that you consider this fact when e-mailing us.
Viruses : We have taken steps to ensure that this e-mail and any
attachments are free from known viruses but in keeping with good
computing practice, you should ensure that they are virus free.

Red Lion 49 Ltd T/A Solid State Logic
Registered as a limited company in England and Wales
(Company No:5362730)
Registered Office: 25 Spring Hill Road, Begbroke, Oxford OX5 1RU,
United Kingdom
**********************************************************************