Actually the mail was sent using:
cat message | exim -bm -odqs
On Thu, 15 May 1997, Nigel Metheringham wrote:
> } 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! ]
>
>
>
