On Tue, 7 Oct 2003 10:21 , Philip Hazel <ph10@???> said:
> 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.
Is not always true for list machines.
>
> 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.
>
Do people use tmpfs for this and does it really help?
--
Alan Thew alan.thew@???
Computing Services,University of Liverpool Fax: +44 151 794-4442
