Matthew,
MaxQueProc is really setting the peak load capabilities of IMail. You would
need 90 new messages coming in all at the same time, for IMail to ever reach
the value you are using. Normal Queue processing starts a single process to
handle the remaining mail files, so the retries does not use anywhere near
the amount of resources as mail arriving the first time (that use one
process per message, for new mail).
I would decrease the Queue Timer, too. With your current setting IMail is
only attempting to process what remains in the queue only once every 4
hours. If this were 30 minutes (the default) it would try 7 more times in
those 4 hours. Now this may not increase the total throughput significantly,
but it will reduce the hold time if a message is not fully delivered on the
first attempt (about 98% are usually delivered on the first try!). Maybe you
want the Queue timer set between 30 and 60 minutes.
If the message is not delivered on the first attempt (those 800 spool files,
400 messages), there must be some reason for that and it should show up in
the log. If there were no problems, the mail would have been delivered! So
you really need to look more closely. A message that is not delivered will
have a message 'requeueing' or a delivery status of (3). Find those and then
look backward into the log to learn more about that specific delivery
attempt.
User not found (or unknown user) should result in an immediate bounce
message back to the sender (with that address removed from the recipients
list). Same with 'unknown host'.
I guess I would also look at some of the files in the Queue, just to see if
there are particular domains or users that show up more often than others.
That could give you a pointer to the cause of the delivery delays or
problems.
Do you have NT Auditing enabled? I would shut that off. I have seen at least
one case where this was on and Audit Logging placed such a load on the
system that SMTP service (and disk access) were about 300-500% of normal
response time. SMTP would take several minutes to send the '220...' line on
a connect (and current connections showed 25-100!) and Disk light was on
continuously.
Daniel Donnelly
________________________________________________________
----- Original Message -----
From: "Matthew Boyce" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, March 01, 2001 8:27 AM
Subject: RE: [IMail Forum] speeding email processing up?
> **I have MaxQueProc set to 90 right now and doesn't seem to have any
affect.
>
> **Spool averages about 800 files (not including log files) which are
mainly
> retires. We have the retries set for 4 hours.
>
> **I have not seen any errors in the log file. Only normal logging of
> connections, greetings, and either successful exchange or notice of full
> boxes, users not found, etc.
>
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Len Conrad
> Sent: Thursday, March 01, 2001 4:02 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [IMail Forum] speeding email processing up?
>
>
>
> >Are there any settings I can change to speed the processing of outgoing
> >mail? We are running 6.06 on Win2000 Server (SP1) dual PIII 866 with 1GB
> >RAM and we are only seeing an output of about 5,000 to 8,000 pieces of
mail
> >per hour.
>
> output = sending only ?
>
> 8000 / hr is ridiculous for that machine. I've seen 40K/hour (joke
> list delivery) on a P500 / 512 megs RAM (but it wasn't Imail) and the
> machine really wasn't sweating.
>
> So something is apparently throttling you.
>
> DNS slowness can certainly hold back deliveries. Your DNS should be
> on a machine separate from the mail server. If you're doing a lot of
> list delviery (email addressed re-used), then having a big cache on
> your DNS will speed lookup as the query ansers will come from local
> DNS cache rather than remote NS.
>
> Scott mentioned the number of SMTP processes in memory. If you see
> 30 or so (I think that's the max default), then maybe you ought look
> up the registry hack in the KB to allow more (the joke list server
> peaks at 350 SMTP processes, you get the picture?).
>
> Figure like this:
>
> 1 msg per 10 secs per SMTP process (rough average)
>
> gives
>
> 360 mgs per hour per SMTP process
>
> 30 SMTP process x 360 msg/process-hour = 10800 msgs / hour
>
> So with 8000 / hr, your aren' that far off. So if your output is
> limited in number of SMTP processes, then 2x or 3x the SMTP processes
> should give you a lot more deliveries.
>
> What is your CPU / memory utilization ? Is the machine running only
> Imail or have you put SQL2000 in there, too? Do you have 100
> simultaneous Web mail connections sucking up the CPU and memory?
>
> Do you have any msgs in the Imail queue? 10's? 100's?
>
> Any errors in the Imail log?
>
> Len
>
> http://BIND8NT.MEIway.com : Binary for ISC BIND 8.2.3 for NT4 & W2K
> http://IMGate.MEIway.com : Build free, hi-perf, anti-spam mail gateways
>
>
> Please visit http://www.ipswitch.com/support/mailing-lists.html
> to be removed from this list.
>
> An Archive of this list is available at:
> http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
>
>
> Please visit http://www.ipswitch.com/support/mailing-lists.html
> to be removed from this list.
>
> An Archive of this list is available at:
> http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
>
Please visit http://www.ipswitch.com/support/mailing-lists.html
to be removed from this list.
An Archive of this list is available at:
http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
