mail service grinds to a halt

[willtech]

from viewtopic.php?f=12&t=287
Yep, this has been dealt with. Sorry about what happened, the timing was unfortunate as we had a long weekend. But after deleting over 20,000 queued emails, I think we are good to go!

Tim

Hi,

I know the quote is from an old post but it seems entirely relevant to my issue.

Whenever the mail service gets under what I call medium load - let's just say batch more than several thousand messages - it seems to choke, get stuck, not record deliver attempts that are successful or otherwise, re-deliver the same messages several times over and eventually grind to a complete halt with high CPU usage.

Is there something particular in the Wingate config I should be looking at to resolve this?

I have tried several things so far - more threads, less threads, process mail more often, less often. The only thing that seemed to help was using 'attempt immediate delivery' which delayed the onset of the symptoms but did not eliminate them.

I'm running Wingate 6.2 2 on XP SP3 on a dual p3 box with 768MB RAM and with the TCPIP.SYS patched to 500, wingate folders and processes excluded from everything.

[adrien]

Hi

do these messages come in on many or few connections? Easiest option might be to choke the rate of inbound messages so that delivery can keep up.

In terms of sending threads, only one thread is used per destination domain in any case, so if all the mail is going to a few domains, then increasing the number of delivery threads won't help. In fact too many threads will bog down the machine with context switching.

What current values do you have for

* number of send threads
* number of receive threads?

You can use bandwidth control to limit the rate of inbound traffic on port 25 (don't choke outbound though). This could be used to slow it down.

Other things to keep in mind.

There is only one single queue processing thread, and one single in-queue AV scanning thread. If you scan prior to accepting it, you'll take the load off the in-queue AV scanning thread. Otherwise a large throughput of mail that is all being scanned by the single in-queue AV scan thread could slow it down.

The other thread is used to route messages to relevant domain jobs. for instance if an email is received for 3 recipients at different domains, the original .rcp file contains all these emails, and the queue routing thread splits this into 3 rcp files, into each domain folder.

Regards

Adrien