Re: [Exim] Bypass disk queue

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Philip Hazel
Fecha:  
A: Avleen Vig
Cc: Jerry Jorgenson, exim-users
Asunto: Re: [Exim] Bypass disk queue
On Mon, 22 Sep 2003, Avleen Vig wrote:

> On Mon, Sep 22, 2003 at 12:44:49PM -0500, Jerry Jorgenson wrote:
> >
> > Does anyone know of a way to make Exim bypass spooling and deliver to the
> > receipient MTA (in a gateway MTA situation). Preferrably based on
> > messages size or MTA load? I've already thought of using a RAM disk
> > approach, but is there any other way?
>
> I believe the RFCs *require* saving to disk before you let the sender
> know the message was received successfully, in order to better ensure
> delivery guarantees.


Indeed, the RFCs require the MTA to have stashed the message somewhere
"safe" before acknowledging its receipt to the sender.

Exim does not keep messages in main memory. It keeps the header lines in
main memory while processing a message, but the body of a message is
written to disk as it is received, and read from disk as it is
transmitted. Header lines are written to disk while a message is
"queueing".

> I know sendmail has a 'super safe' option, which if you turn it off, it
> won't spool to disk, but I don't know if exim has this.


Exim does not have this. I didn't see the point of all the complication
of keeping some message bodies in main memory - and then having to write
them to disk if they couldn't be delivered immediately (or were too big,
or whatever). It would be a lot of messy apparatus for, imho, not very
much gain.

Note also that Exim's "queue" *is* the set of files in its spool
directory. There is no separately-maintained list of messages that has
to be updated in an interlocked manner. Coping with anomalous messages
that don't get to the spool would be yet another load of complication.

I'd rather keep it all very simple. Usually that gives better
performance in the end.

A RAM disk is clearly the answer if this kind of performance is needed
and you are prepared to take the risk. If you do this, you might as well
also build a version of Exim in which the fsync() function does nothing
(this can easily be done by turning fsync() into a macro). Doing this
has been reported to improve performance noticeably, but I don't know if
this was done in conjunction with a RAM disk or not. The application
was sending out subscribed-for bulk mail, where losing a few messages
was not a big deal. I would not recommend this in situations where the
mail that is being handled is not something of this kind.

Other related things that do not involve the risk of losing mail:

1. Put Exim's hints files on RAM disk.
2. Turn off the use of message_log files.

Philip

--
Philip Hazel            University of Cambridge Computing Service,
ph10@???      Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book:    http://www.uit.co.uk/exim-book