} The 100.000 mail were sent using
}
} cat message| exim -bm ...
Your earlier message said you were doing this in a loop with a single
recipient per invocation.
So effectively you are starting up exim 100,000 times and waiting for it
to deliver (or fail to deliver) each invocation. You have serialised 90%
of your mail processing, so I am not surprised this ran rather slowly.
} This in itself brought a load of 3 on the system.
I guess you might be having a short period with a 100% CPU usage (if
available) from the exim process as you launch it and a longer period of
waiting around to see if anyone is at the other end. Simultaneously you
would be having queue runs of your old/bounced mail coming up, so I would
say a load of 3 under such circumstances is remarkably restrained.
} The message queue grew
} to 25.000 entries (in part because of some permission issues with the mail
} directory of the user who got the errormessages back).
Well this can't all be blamed on exim - a reasonable starting setup helps..
} Delivery for off site messages was also very slow. We could never get exim
} to deliver more than one message per second. Finally it was decided that
} exim is unsuitable for such a purpose. Qmail is lurking on the horizon...
} Is there any way to get exim to do faster deliveries?
Thats probably not bad for a linux box unless the connectivity is very
good. In your case some of the speed ups could not work because the
messages were injected one per recipient. Basically you are running exim
like qmail, but whereas qmail is designed to be run like qmail, exim isn't!
If you had a single message with lots of recipients, parallel deliveries
configured and a few other bits I would have thought that it would have
worked a lot better. It would also not have filled the queue.
} Also had segfaults due to a corrupt Berkeley DB database. After
} removing the database things went almost back to normal again.
Have these db's started life with an earlier exim - a version or so back
there was a problem in the locking code for the db stuff.
There is an updated berkeley db - 1.86 - which will work with exim and has
a bug in the hashing code removed. However I do not know if exim's db
usage is such that the bug would have been tickled in the first place....
db 2.0.x is a rather different beast and I would not recommend trying it
with exim unless you really like the bleeding edge.
Nigel.
--
[ Nigel.Metheringham@??? - Systems Software Engineer ]
[ Tel : +44 113 251 6012 Fax : +44 113 224 0003 ]
[ Friends don't let friends use sendmail! ]
