Scalable Mail solution with NAS

Wed Jan 31 16:06:09 UTC 2001

On Wed, 31 Jan 2001 Valdis.Kletnieks at vt.edu wrote:

> On Wed, 31 Jan 2001 10:13:40 EST, chrisb at 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 at 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 at zeroknowledge.com