On Wed, Oct 23, 2002 at 01:33:29AM -0200, Paulo Henrique Baptista de Oliveira wrote:
> --
> Hi all,
> I want to run Exim for a great number of messages/day (1 Milion or more)
> in a i386 machine.
> I installed Exim 3.35 in a Debian GNU/Linux woody server.
> The following are the specs(cpu, mem and bogomips):
>
> model name : Intel(R) Pentium(R) 4 CPU 1.70GHz
> cpu MHz : 1715.328
> bogomips : 3420.97
> free
> total used free shared buffers cached
> Mem: 254972 248740 6232 0 28044 205508
> -/+ buffers/cache: 15188 239784
> Swap: 506008 0 506008
>
> Exim is configured without any tweaks.
> We wrote an small C program to send 200 messages through Exim.
>
> ./test
> Wed Oct 23 04:11:11 BRST 2002
> Wed Oct 23 04:11:49 BRST 2002
>
> The program indicates that Exim can handle only 5 mes/sec! ;(
> (200 mes/40s).
> This is so bad.
> What I can do to improve this number?
> I' m atacching the exim.conf too.
> Much thanks, Paulo Henrique
I'm certainly no authoritative body on this but I don't think you're going to
get that kind of performance on a single processor 1.7ghz intel box running
any kind of operating system that i've ever seen.. You're not just going to want
to performance tune exim you're also going to need to tune your operating system.
Basically I think what it boils down to is that you're going to need more hardware
to handle over a million messages per day. I've seen implementations of exim as
a relay with 10-20 multi-processor machines running a commercial unix like Solaris
that can easily handle millions of messages daily.. but the most I've ever gotten
exim to do on an intel box is about 200k-300k messages per day. Which is still
quite a bit of e-mail to relay.
You'll want to make sure that your dns queries are answered very quickly.. I
wouldn't suggest running a cacheing name server on the box locally, because
that just takes away cpu and sockets from exim, but a cacheing name server
local to the machine less than one hop away on the same subnet would be
good.
Look at some of the following config options as well:
deliver_load_max
deliver_queue_load_max
queue_only_load
smtp_accept_max
smtp_accept_max_per_host
smtp_connect_backlog
queue_run_max
smtp_receive_timeout
In the remote_smtp transport configuration I've found that setting
connect_timeout to something lower than the default (for example:
connect_timeout = 120s) helps a little bit.
Using a fallback smtp server is also key to being able to relay more mail. This
allows you save processor/io time by not having your machine busy doing queue
runners constantly..
If you're delivering a lot of mail to a handful of domains, setup custom retry
configurations for them. It's worth it.
Remember that logging takes up disk io and cpu time as well.. the less you log
the less io/cpu that exim uses.. granted you're only talking about fractions of
a second of time here, but those fractions of a second add up over a 24 hour period.
Especially when you start to talk about incredibly high volume relays.
Good luck!
--
Greg Poirier
System Administrator
EarthLink, Inc.
-------------------
What beats global warming? ... NUCLEAR WINTER!
