Grant,
Well, I cannot say I have a resolution, but there are some more things you
can do to track this down or reduce the impact.
I'll assume you have already done all the checks of your Aliases for less
than 50 addresses and/or other aliases that would cause the total number of
addresses to exceed 50. If you have not, please do.
First, you are correct that this situation can often resolve itself, with
the server 'running slow' (actually just does not have enough SMTP32
processes to deliver each message immediately), if left alone for a while.
See it more than once myself. You might increase the number of SMTP
processes using the registry change, but don't increase by more than about
50% without careful observation of the results on your system resources
(will need more free memory, for more processes!). This list server runs
with MaxQueProc set to 60 on a 256M system that processes lists only (ever
consider another server just for the large lists?)
Second, it might be possible to adjust your List Server settings to minimize
the load/need for SMTP32 processes. The 'Number of Recpients' for each list
might be increased, so there are less messages for IMail to process (but
each message goes to more users).
Now, you can follow all the steps in the KB article, but maybe there is an
easier way to find the problem message. Look in the \imail\spool dir and
look for D files that have no corresponding Q files (often these files are
the oldest D files, older than the elapsed time the message could have
stayed in the Queue [multiple the SMTP 'Queue Timer' setting by the SMTP
'Number of Tries' to get this time in minutes]). If only the D remains, this
is a message that IMail could not deliver or return and is not deleted. If
you open them with Notepad, you may see a pattern, that could lead you
closer to the problem. If you see the same email address(es) always
involved, maybe that one should be removed from the List.
The only other thing I could think that may help you get around the buildup
of SMTP32 processes, would be to have something check or report the current
number and then run kill.exe if a particular value is exceeded. This could
limit your IMail performance. Maybe some way to figure a running average
number of SMTP32 processes, over a modest time, would be a better way to
figure the load and kill based on that number.
Is someone responsible for checking 'bounced' email from the List Servers?
Having lists that don't get cleaned up on some regular basis, can impose
loads that are not necessary. Some mail servers will accept mail for their
users, even though they do not actually exist, and then return email to the
list admin, telling them of this situation. Timeouts when attempting to
connect to mail servers that do not exist, can cause processes to stay open
longer than needed, too.
The only reason I concentrate on Lists is that 1, you mentioned them and 2,
even modest but unmaintained lists can cause the mail volume to swell quite
quickly, to become much more than the total of all other email. List
optimization, relative to SMTP32 processes and your systems resources,
become much more critical. Of course, CPU performance, RAM and disk speed
are also considerations that can affect performance.
The second item I mentioned, could have a greatest effect on your system, if
you have more than just a couple of lists, with each having only hundreds of
users. If you have a single list with 7500 users, a single email message to
that list, with the default List settings, could cause all (30) of your SMTP
processes to be running in an attempt to send the message to all the
subscribers! Now any new mail that comes in, cannot be processed and won't
be tried again until the Queue Timer elapses (default of 30 minutes) and
there are free SMTP32 processes.
One last thing, don't set a Lists 'Number of Recpients' to 2000 or above.
Someone reported that a value this large, did cause a SMTP32 problem (in an
older version of IMail).
Daniel Donnelly
________________________________________________________
----- Original Message -----
From: "Grant Griffith" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, September 25, 2000 8:16 AM
Subject: Re: [IMail Forum] For Len and IPSwitch ----------- READ
THISIPSWITCH. PLEASE.
> >>We're having these damn SMTP problems again and they tell us
> >>the same thing "copy all 19,000 backed up spool files to a temp dir and
move
> >>them in bunches to find the problem".
> >
> >yep, a f@cking nightmare. Sorry about your Sunday.
> >
> >Did Grant 8Legs get his similar pb fixed?
> >
>
> Depends what you call fixed???? Things are running smooth again on our
end. I was out all day Saturday, therefore messages were moving very slow
all day. However, come Sunday morning it appears that the culprit messages
either finally made it thru or finally were returned to the sender. I do
wish this would not happen, but it appears it is just a certain type of
e-mail that cuases this. And with the list volume we have, it would be VERY
hard to track it down.
>
> Therefore, it appears if you let it ride, it fixes itself. However, it
REALLY slows things down to a crawl which in my opinion is not acceptable.
>
> Grant Griffith
> http://www.getafreewebsite.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/
