Note: maybe this is not new for certain people on this list but as it was not easy for me to resolve it, and also neither Ipswitch seems to know this. So I want to tell you what happened me with our brand new server:
Our new Win2k3 Dell server with Dual Xeon CPU's, 2 Intel and 2 Broadcom Nic's has had the problems that after a short time of higher smtp traffic more and more connections failed. This problem was already described by several people on this list, and Ipswitch's solution was to buy "a bether NIC" (I must laugh again any time I hear it :-) Well, the problem was here, the new machine seemed working poorer then our previous "4 year old noname-assembled server" with realtek NICs. It was a little bit of work to explain to other people in my company that we need a "bether NIC", nobody has heard this before even if working for over 15 years in the hardware/server business. Ok new 3Com neek arrived, disabled 4 (four!) preconfigured Dell NICs and attached the 3Com card to the network. Run the test again: gatewaying 1000 messages each one send with a delay of 300 ms trough the server. (more the 260000 msgs/day) Surprise! The previously in hundreds appearing "MX CONNECT FAILED" and "status=3"-lines in the logfiles has reduced down to around 30. But successfull delivering 970 fom 1000 messages it not acceptable, even if the missing 30 was requeued and delivered with the next queue run! Searching the archives I've found Sanford Whiteman's post about TCP registry settings: http://www.mail-archive.com/[email protected]/msg94971.html After changing this two values (TcpTimedWaitDelay: 60 seconds / MaxUserPort = 25000 ports) there was not more one single "MX connect failed" or "status=3" in the logfiles. All messages was delivered immediately. Watching the "forgotten" TCP-connections left by Imail in WAIT-STATE with "netstat -n 5" I've discovered that the connections from the random local port to the remote port 25 remain in wait state for a to long time (default=240 seconds) so that after reaching the default MaxUserPorts limit of 5000 and beginning new from port 1 on each try to connect from an local port already in WAIT-STATE will cause a MX CONNECT FAIL and so a requeueing of this message. So by reducing the TCPTimedWaitDelay down to 60 and increasing the MaxUserPort there was enough time for the OS to free up the forgotten WAIT-STATE connections before the connection limit was reached and so there is no more conflict and no more errors. (until the number of processed messages in a short timerange will become high enough to catch the tail again) Now back to the subject of my post: Removed the 3Com re-enabled the Intel Nic with the new registry settings suggested by Sanford: No errors even if sending 400000 messages trough the server. It seems to me that the onboard NIC of the DELL processor are even more performant then the 3Com nic but that is not confirmed by a scientific test. So please forward the bills of your 3Com NICs to Ipswitch, or maybe ask a credit to buy ICS... ;-) Markus To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
