Gordon,
>Thanks for the queue & disk controller suggestions. I'll look into
>implementing them.
good, we'd like to hear how it works out.
Anyway, obviously the health org you're doing this for is absolutely
swimming in excess profits, let's swing for the fences:
There a three major type of disk activity that Imail requires:
1. The user database, in the registry, usually on drive c:. We know this is
sucky MS "innovative (Bill said so)" system design with poor performance in
general and no MS-supplied way to re-index and re-compact a fragmented
registry (like MS said about NTFS in 1996, "it doesn't need
defragmentation, that's why we don't deliver defrag tool". yeah, right. Why
does anybody still believe these guys??).
Even if Imail uses an external SQL database, Imail stills queries the
registry to know if a user account belongs to Imail. For incoming mail,
Imail doesn't do an ODBC/SQL query just to see if the account exists. Imail
queries the registry database: yes, this user@domain is Imail's, so accept it.
2. The spool (aka "mail queue") directory, where all incoming and outgoing
mail is queued up, including the attachments, while waiting for delivery
locally to user mailboxes or for delivery remotely to other mail servers.
This is also the Imail log file directory.
3. the domain\users mailbox directories, where Imail stores, well,
hmmm. The worst case is yours where POP3 is turned off OR IMAP, both cases
leading the users to keep a lot of their mail on the server and very large
mailboxes. (continous defragging recommended)
All 3 of these databases are very actively accessed in real-time for nearly
every single msg that arrives or leaves. Lots of disk activity.
The optimum hardware configuration would be to have 3 separate SCSI
controllers with 64 or 128 megs of cache (see Asus boards) and 3 disks so
that Imail's multi-threaded processes could keep all three disk channels
busy in parallel (ie, overlap the 3 disks' i/o), rather than have all those
godzillion SMTP, SMPTD, POP3, IMAP processes blocked waiting for one disk
to do all 3 types of database access. eg: an SMTPD process can ask the
resgistry channel if user@domain exists, while a POP3 process can read mail
from the mailbox channel, while SMTP client process can be reading mail
from the mail queue channel to send mail. "As good as it gets" for
matching multi-threaded CPU processes with overlapped disk i/o.
You can't split the registry or \spool database across drives, but if you
have 10's or 100's of 1000's of users-mailboxes, you can certainly put some
domains\users on one drive and other domains\users on other drive(s).
One alternative I'm looking at for my "appliances" is Promise FasTrak 66
IDE RAID controller that supports RAID1 mirroring. But I'm not sure you
could put 3 in one PC. But it sure would save a ton money on disks, since
IDE disks are so cheap now vs. the same drive with SCSI i/f. The drawback
with IDE is that it usually takes a ton of CPU work vs SCSI where the SCSI
card does most of the work. But I suspect these FasTrack cards do all the
tedious low level i/o with the disks and probably don't burden the CPU any
more that SCSI controllers.
>(I appreciate your unique sense of humor as well.)
You're weird, Gordon. vbg
Len
Please visit http://www.ipswitch.com/support/mailing-lists.html
to be removed from this list.
