Recently, we've been battling the queue which ends up having about 350k messages in it.
That's not Imail fault. Something outside of Imail has gone wrong to let that situation arrive.
NO filesystem can handle 350k files in one directory well. In FreeBSD, with 140K files in the postfix queue (it was a setup error by the Imail admin), and even using a hashed directory tree to spread the 140K files over a two-deep directory tree, the queue processing was a dog. (but there was no failure, just decreasing slowness until the queue count became sane again)
SMTP goes crazy at times and maxes CPU.
We see that in the list here repeatedly, in the past few days. It appears that a garbage msg into SMTP will trash the SMTP process, it becomes a zombie process, repeatedly, until memory is filled and no mail moves. old problem.
Email administration takes about 25 minutes to load (7k users).
That's not new, either. No one can manage more a couple 100 records in an HTML <SELECT> box, which doesn't scale to 1000 or 10s of 1000s of records.
To admin a database, you need a database application (query with criteria, add, delete, modify, save). Does anybody know of integrated mail program with a database manager running through a web interface? Does MS provide one for Exchange?
SMTP refuses connections because there aren't enough smtp connections available (which the FAQ says not to increase because it puts too much of a strain on the server, however we have 7 times the amount of connections on our Qmail server without any problems).
Not a new problem. Well Imail isn't qmail, and Windows tcp/ip stack isn't a Unix stack. Windows process manager isn't Unix's process manager. (And Ipswitch isn't MS. We know MS-the-applications-company would like to kill Ipswitch along with all other providers of strategic, infrastructure apps running on Windows from MS-the-OS-company.)
If you don't have whatever it takes to purchase/tune your Imail server to scale up to the apparent large volumes you have, I suggest you go a multi-box solution and use an MX front-end:
1. to reject 50+% of the incoming mail as spam,
2. to shorten the SMTPD session time to 1 or 2 seconds by accepting all mail from the front-end MX machine, lessening the need to have each SMTPD session last 10+ seconds, sometimes 10's of seconds. (your filesystem will have to be fast to queue incoming)
3. to accept the Imail outbound mail with short SMTP- sessions sending to a fixed IP address (no DNS lookup, no deferrals, no queueing), having the same effect on the process count as 2. above.
In brief, it sounds like you are having scaleablity issues within IMail and are making the mistake of trying to scale the mailbox server while asking it to the the MX function.
By the way, this happens on multiple servers.
you know my email address. :))
One issues in the past that we struggled with Ipswitch on was: Using multiple CPUs causes very strange problems. They now say not to use Multiple CPUs
I don't remember seeing that here in the list. There must be 1000's of Imail boxes running 2 CPUs.
We have been in touch with Ipswitch lately. They say that if we upgrade to version 8, install everything on a new box with RAID 0 + 1, have the files contiguous, we should probably see our issues go away. What have others seen with Version 8? Was the upgrade easy?
The big item in 8 that would appear to affect you the most is the new queue manager.
But there are many non-Imail dimensions to scaling up mailbox server(s) for very high volumes. Multi-box should be an early tactic in scaling-up.
Len
_____________________________________________________________________ http://MenAndMice.com/DNS-training: New York; Seattle; Chicago IMGate.MEIway.com: anti-spam gateway, effective on 1000's of sites, free
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/
