On Wed, 31 Jan 2001 Valdis.Kletnieks@vt.edu wrote:
On Wed, 31 Jan 2001 10:13:40 EST, chrisb@kippona.com said:
Is the number of mailboxes the key metric? What breaks sendmail + "a very big disk"? Isn't it the traffic?
The two biggest problems with very-high-volume servers and sendmail are:
1) You *really* need to use multiple queues and some sort of aging scheme, so mail backlogged for dead hosts gets out of your main queue. If a queue gets too full, Sendmail exhibits bad O(N**2) behavior in sorting/running the queue.
2) If you are serving mailboxes (as opposed to a Listserv-type machine where the mail *leaves*), what can kill you isn't the sendmail, but the local delivery program and POP/IMAP checks. You get enough bozo users who have set Eudora to check for new mail every 2 minutes, you'll get bogged down no matter HOW fast Sendmail itself is.
Your second point should in fact be splitted in two. 1. Your going to have a hard time handling the amount of incomming pop connections, yes. That's true, and there's nothing you can do about it execpt scale your server farm in consequence or deny consecutive connections within a 5 or 10 minutes period. 2. The more mailboxes you have, the slower the entire popping process will be. The reason is very simple, each pop process will spawn and read your mailbox directory. In the case where you have delivered all your mail to mailboxes all sitting in the same directory, it will take more and more time to scan the directory to find your mailbox. One way to fix this issue would be to use a hashing scheme to split the amount of actual mailboxes into a subdirectory structure. You could get something like johndoe@yourdomain.com would have his mailbox in /export/mailboxes/j/o/h/n/johndoe.mbox so in /export/mailboxes, in order to find the j directory, you only have about 36 directories entries or so. Although this example is not good in the case where you accept usernames with 3 or less characters.
-- Sebastien Berube sberube@zeroknowledge.com