On Mon, 6 Oct 2003, Avleen Vig wrote:
> You'll see a problem, when you're using exim on a fallback in this
> situation. The server is trying to connect to machines which have
> recently been known to be unavailible. So the changes of writing to the
> retry database are *high*. I really is pretty bad.
> At the same time you've accepting new mail from your relays and tryign
> to deliver that, which also causes rights.
> Finally when you manage to flush the mail for a domain, that also causes
> writes. Lots and lots of writes. Only one queue runner can write at a
> time. Bad.
The underlying problem is that Exim was just not designed for this. I
designed it to work well in my local environment. This is a University
system, with fast Internet connections, where well over 95% of messages
are delivered first time. That was the case back in 1995, and it is
still the case. Yesterday, for instance, one of our machines did this:
At least one address
TOTAL Volume Messages Hosts Delayed Failed
Received 255MB 11546 215 65 0.6% 156 1.4%
Delivered 300MB 15043 590
That shows 99.4% delivered first time. That is why the retry mechanisms
are all in the form of hints, and why they are pretty crude. I was
assuming that these features would be used only very rarely. I also
assumed that queues would normally be short.
In environments where the queues get long and many messages cannot be
immediately delivered, the way Exim works is less than optimal. That's
unfortunate. If only I could have foreseen just how widely it would be
used... Actually, that probably wouldn't have helped much. I knew a lot
less in 1995 that I do now.
--
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
