Re: [Exim] Exim is Unreasonably slow

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Exim User's Mailing List
Date:  
À: dgtech
CC: Exim User's Mailing List
Sujet: Re: [Exim] Exim is Unreasonably slow
[ On Friday, May 7, 2004 at 07:12:04 (-0400), David Garza wrote: ]
> Subject: [Exim] Exim is Unreasonably slow
>
> The email goes strait into the queue, which is only at 27.5 emails per
> second, which is very slow for just queuing it.


Not really, given your server's stunningly decrepit mass-storage
subsystem..... (even if it's an 80-pin ATA/100 drive with the right
cable, it's still just a single spindle not doubt just 7200rpm or slower
and with a single head arm, and likely not much cache, and probably not
even rated for 7/24 operation)

> I need something much faster.


You need better hardware!

Try replacing your lone (and perhaps not even server rated) IDE drive
with a pair of (or 4) modern Ultra320 15k RPM SCSI drives using software
striping (i.e. RAID-0). Get drives with lots of cache RAM (>= 8MB) and
turn off write-through so that it can be used for writing. Make sure
you have a reliable and well tested UPS and don't run any experimental
kernel that might crash. (or double the number of disks and run RAID-0+1)

Or get a decent multi-channel S-ATA controller and do the same with some
10k RPM or better server-rated (i.e. 24/7 operation) S-ATA drives.

Or get a multi-channel ATA/100 or S-ATA RAID controller that can do
RAID-0+1 all by itself and has lots of on-board cache of its own, and
get two or more of the fastest appropriate server rated drives you can
afford for it.

> I cannot run the
> queue at the same time as I run the script or else the load goes to high.


Where did you get the mistaken idea that the mythical "load average"
measurement has anything to do with actual throughput?

Ignore the load avarage -- it cannot tell you anything really useful.


> I read on the internet that a server was able to get 42 emails per second
> with a 1.13MHz server.


Where did you get the mistaken idea that CPU clock speed had anything
whatsoever to do with filesystem throughput?

Your CPU is not your bottleneck. It could no doubt caclulate _many_
_millions_ of RC5-72 keys per _second_ for distributed.net (an old
P-II/300 can do ~1.2 million/s flat out) at the same time as it waits
for your lone disk spindle and head arm to thrash about.

Note on that hardware you should probably be running the latest
FreeBSD-5.x with soft-dependencies enabled filesystems too. I think
you'll also need to tune the kernel to use a good chunk of that RAM as
buffer cache.


> My problem is, it does not send fast enough. It takes a total of 15 minutes
> to finish off the queue using this method, which is overall 8.8 emails per
> second, which is very slow. I need something much faster.


If you're spewing out (spam? I hope not!) e-mail to the internet then
the speed it goes out at will depend entirely on the latency and
bandwidth of your backbone connectivity, whether or not you've got a
separate, capable, host on your LAN running as a caching nameserver
(i.e. set up a separate machine to run named!), etc., as well as on how
many parallel queue runners you actually run (75 would be quite a few,
but not a lot, if you were actually running that many concurrently; and
your deliver_queue_load_max is way too low).

--
                        Greg A. Woods


+1 416 218-0098                  VE3TCP            RoboHack <woods@???>
Planix, Inc. <woods@???>          Secrets of the Weird <woods@???>