Quoting Bart Dumon ([EMAIL PROTECTED]): > On Wed, Jan 21, 2004 at 03:55:13PM -0800, The Little Prince wrote: ... > > Forgive me bart, it just totally went over my head that you and I had > > talked a while ago when you had the rename() problem. > > When you said NAS and nfs, the little light bulb went on above my head > > :-) ... > yes, 320k mailboxes, 4 servers.
More important numbers include concurrent access. In dialup days, the good number for ISPs was 1% would be hitting pop mail. (10% connected, 10% of those hitting mail). Used here, that says 3200 concurrent users, which I'd have no qualms with on any single unix box. Recall two that an NFS link appears in load average, because of where NFS lives in the kernel. I've had a slowing NFS server bump fairly responsive machines to loads in the 100's. (I did get, after 5 minutes, an LA of 2050 once - as a large server was just tanking. Machine was not responsive :) I've worked in environments where 320k wasn't a great challenge, but it's a different world that 1 box with lots of *good* RAID. Doing the Earthlink type model, we used mbox, but we did LOTS to deal with NFS locking - changes to mail.local and qpopper. NFS (generically NAS) does mean MUCH slower disk access. My favored RAID boxes let me write to them at 70MB/s per box (I've put in multiple controllers and used software striping across RAID boxes for more). A good 1GB connection with decent (not windows) drivers will give you around 300Mb/s at best. (ttcp on a quiescent two machine network may give better, yes, but not on a real network). For practical math, we can call that 30MB/s or less. Plus delays for the server to get and write files. (In the past, we've used only 4-8GB of Netapp disks because the bottleneck was spindles, and using 36GB disks just exacerbated things). So it's doable, but LA is a finger in the wind - you won't know about the weather much. nfsstats and looking on the NFS server will tell you lots more... Another approach, favored for IMAP servers that should't use NFS, is a proxy that takes your POP session, authenticates you, looks up your name in some directory (LDAP is good) and then connects you to "your" pop server (authenticating you if needed) and becoming a passthrough. A well written proxy client, threading not forking, can handle HUGE numbers of connections with little strain. In fact, the machines can be fairly light weight. You need a tcp stack, not a CPU. A P500 does fine. Additionally, the TCP connections to the pop servers are all on fast and local links. You can safely reduce the timeouts for TCP sockets to WAIT on the backend servers. Also, TCP windows will be fairly large - the backends will never ever deal with a user on a poor, slow or modem link. The TIS Gauntlet firewall had a pop proxy - based on plug-gw that could have been modified for this. But the license disallows it. And you'd want lots of threading.
