Re: Nightmare with exim

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: John Henders
Fecha:  
A: Exim List
Cc: ph10
Asunto: Re: Nightmare with exim
On May 15, Philip Hazel <ph10@???> wrote:
>
> 3,600 per hour. Hmm. John Henders reported yesterday on a system that
> was doing about double that, but he was using a dual processor sparc 20
> with 512 meg of ram. Of course, the speed of the network link is also
> relevant.


Just a note about our stats. The Deliveries would mostly be local writes
rather than network deliveries. That said, I've seen (and possibly noted
to the list, check the archive if interested) outgoing deliveries fly on
exim when our primary west coast mail machine went down and didn't get a
replacement hard drive for almost 24 hours. The primary MX host was a
Pentium 100 running SCO 5 with exim and it delivered about 7000 messages
in less that 2 hours when the main machine came back online. Granted
that was probably down only a few smtp connections, but it shows exim
doesn't have any throughput problems. I found the old stat file so
here's the excert.

03-04 4632 .................................................
04-05 2527 ...........................

There were no specs posted for the linux box in question, but if it was
low on memory and swapping with all those exim processes running that
could explain the problem, as Linux still seems to degrade heavily under
heavy swapping, often quite a bit more than other unixen. Discussion
I've seen on the kernel list says that will hopefully be addressed after
in the 2.3 series.

Whether qmail will be the answer I don't know, as it has a one message,
one connection scheme for delivery, so the number of processes might be
more to deliver the same mail. Unless the qmail delivery process is
considerably lighter weight than exim, the same performance might
result. Possibly zmailer might work better though from what I've heard
about a few boxes in our company zmailer doesn't appear to be much
better than current sendmail and exim is definately more efficient than
that (see my previous mail on that subject)

Personally I would have tried making exim handle all that mail in
queue-only mode and then limited the number of exims that would run the
queue to keep the box from swapping to see if that improved performance.



-- 
      Artificial Intelligence stands no chance against Natural Stupidity.
                GAT d- -p+(--) c++++ l++ u++ t- m--- W--- !v
                     b+++ e* s-/+ n-(?) h++ f+g+ w+++ y*