On Tue, Jun 26, 2001 at 04:52:04PM +0100, Rob Butterworth quothed:
> >What does eximstat gives you?
This will give you an idea of the split per day and domain of the mail
send. It is well worth using.
> >How many queue runners run at any one time?
>
> Not sure. The default I expect (5?)
ps -ef | grep -c exim
> >Where are they sending mail to?
>
> Other employees inside the company (on other mail servers), plus many
> outside addresses.
Again, look at eximstat it should tell you more than that and maybe you
can identify the problem.
> >Is there a network problem along the route out?
>
> I've seen processes delivering to our US mail servers grow to hundreds of
> MB, even through I can easily telnet to them manually on port 25 and send
> mail using SMTP commands, whilst the exim process is sitting there eating
> resources...
Right, then there is something going wrong with the way exim deals with
it. Try using something like exim -v -M <ID> of one of the messages and
see where it hands. Or if you feel particulary brutal, strace it.
> >See above. I don't think the problem is in Exim or the way its databases
> >work.
>
> Surely an exim process should *never* use this much resource ? Even if
> it's hung on trying to contact a remote site, surely using all the
> resources the machine has available is not correct behaviour ?
And how do you tell it that? You may spend far more time checking
resources (which is VERY expensive) rather than actually donig the work.
I ran a mail system that tranfered about 20 million mails a day and the
re-try were tiny -- few megs.
You could implement a fallback server that takes the worst offenders off
your mail machine. For example if the message is older than 4 hours,
send it to the fall back and let it take care of it. The fallback is a
normal box, buit which spawns exim queue runners once an hour.
--
www.kierun.org
Yann@??? Use Pretty Good Privacy.
