[KLUG Members] NFS / server tuning for mail storage?

[Bruce Smith]

Cyrus-IMAP solves the problem by keeping each message as a separate
file, that way the system doesn't have to read through one huge mbox
file (the entire folder) each time to read/delete/move a single email.

 - BS



> Having solved my courier-imap/vmailmgr, then having moved to qmail-ldap
> with courier-imap/pop3, I'm getting farther along in my testing and
> noticing that when mailboxes get larger than a few thousand messages,
> the mailbox is effectively useless.
> 
> The server will either spend time with imapd at about 10% usage, with it
> waiting on the network, or imapd will take up ALL the cpu, and spin for
> quite some time.
> 
> My configuration is this:
> 
> Netapp, with gigabit connection to the switch.
> 
> Server: 800 MHz serverblade, 512 MB RAM, 100Mbit connection to switch.
> 
> -
> My plans are to use LVS and balance say, 3 to 4 servers from the 800 to
> 1200 MHz range handling mail services, with them all connecting to the
> netapp back end via NFS.
> 
> But my fear is that people are going to have huge mailboxes, imapd will
> sit for minutes on end, the users will get frustrated, and then complain.
> 
> Are there more effective NFS options for these servers to use?  Right
> now, I'm using soft, noatime, tcp as my options. I don't know if using
> TCP is any *faster*, or if setting the rsize or wsize will help any either.
> 
> Furthermore, should I be splitting up my services? The 1200 MHz systems
> will have 1 G of ram instead of 512, should I use those for imap/pop
> processing and the slower, 800 MHz systems for SMTP?
> 
> Any ideas would be most appreciated. I've worked pretty hard on this,
> and I'm wondering if there's a fundamnetal speed problem that I won't be
> able to overcome with more serverblades, or if there's other ways I
> could squeak more performance out of them.
> 
> Adam