SMTPD Connections Total - 379,093 Occurrences Description
2,724 216.74.144.15 2,695 216.74.144.14 2,622 216.74.144.13 953 209.133.28.63
VERSUS
SMTP Remote Host Deliveries Total - 23,770
24K msgs is only 1000 hour, 1 every 3 seconds. That's really a very light load for msgs delivered. The question is how much resources is tied up handling "380 K connections", whatever that is.
not very useful stats. "SMTPD connections" vs "SMTP msg deliveries"
ime, a lot of SMTPD connection don't proceed to msg acceptance, but timeout, back out, stop, or whatever. That activity does consume gateway resources, but the key gateway numbers are the total number of msgs rejected vs the total number of msgs accepted/relayed.
The weakness of the Imail as gateway is that most/many/all? of the accept/reject decisions are made AFTER the entire msg is received (after the expensive DATA command) in most cases, rather than after the RCPT TO: command. So it costs the gateway a lot of resources to reject 300 K mgs (est. out of 380 K SMTPD connections).
In contrast, nearly all IMGate machines are setup to reject after RCTP TO:, so rejecting 300k msgs/day for a 1 GHz IMGate machine is a breeze.
I know that there are people on this list that Run Imail Gateways/Servers that see way more volume than I do.
IMGate is great for rejecting 75+% of inbound mail as spam and/or for unknown users and handling all outbound deliveries to Internet, greatly reducing the load on the Imail (+ Declude + Sniffer + whatever) box, speeding up the "user experience" and increasing the useful life of the Imail server.
However, the IMGate reduction is sometimes not enough to allow some Imail boxes to keep up with the reduced inbound traffic. ime, a lot of Imail boxes are on the edge, even behind IMGAte, and spikes in load pass right through IMgate cause the Imail boxes to fall over, and start refusing mail from IMGate.
To know precisely what is causing your gateway queue problems, you need to look at your gateway machines' mail logs to see if the Imail mailbox server is refusing connection attempts by the "SMTP" processes in the gateway machines. If yes, then you need to work on the fixing the throughput of the IMail mailbox server, not on the gateway machines. but 23k msgs delivered to Imail is a very light load.
Since the IMail gateways don't have the disk i/o of mailbox read/write nor the heavy load of supporting iwebmsg RAM + CPU + disk i/o, they should be much less loaded than your Imail mailbox server, which is where I bet your congestion really is. ie, the gateway queue problems are symptoms, not causes.
It's quite amazing that a dual Xeon and fast SCSI can't keep up with your 24 K msgs relayed.
And would be extremely condemning of Imail-as-gateway if such a $$powerful box can't implement your policies with whatever software it runs and keep up with rejecting 300 K msgs/day.
Should I replace the PIII with another Dual Xeon and Run ROUND Robin DNS for load balancing?
DNS doesn't provide any (smart) load balancing, only (dumb) load distribution across the destination IPs. Playing with DNS won't fix your problems.
Len
_____________________________________________________________________ http://MenAndMice.com/DNS-training : San Jose; Chicago; Wash DC; Atlanta http://IMGate.MEIway.com : free anti-spam gateway, runs on 1000's of sites
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/
