The Disk I/O subsystem is one area where much optimization can be accomplished. However, before you try to optimize the disk I/O subsystem in your computer, you should understand the following background information.
Microsoft Exchange Server issues I/Os to the disk subsystem on the server to read data from disk into memory or to write data out to permanent storage. For example, when a user opens his or her Inbox, the set of properties in the default folder view must be accessed for each of the first 20 messages in the Inbox folder and returned to the user. If this information is not cached in memory on the server from a recent access, it must be read from the server information store database on disk before the action is completed. The disk read I/O is synchronous to the user-initiated action.
Similarly, if a message is transferred from another server, the message must be secured to disk before the receipt of the message can be acknowledged. This prevents message loss in case of power outages.
The disk I/Os issued by Microsoft Exchange Server are either reads or writes and are either synchronous or asynchronous. Additionally, while all read I/Os and asynchronous write I/Os may be considered random, many of the synchronous writes issued by Microsoft Exchange Server are sequential. That is, a special method of writing changes to disk known as a sequential, write-ahead transaction log is used to speed up actions that require synchronous write I/O.
If the I/O to the drive is completely sequential in nature, the disk head generally does not move at all and only occasionally needs to shift over a single track. The average seek drops close to zero, dramatically increasing the number of disk I/Os per second that the drive can support.
For this reason, hosting Microsoft Exchange Server database transaction logs on a dedicated physical disk drive is critical in ensuring good disk write I/O performance. Placing the information store transaction logs on a physical disk with no other sources of disk I/O on the drive is the single most important aspect of improving Microsoft Exchange Server performance.
It is best to use the file allocation table (FAT) file system for this drive because it performs the best with sequential activity. However, note that the Windows NT file system (NTFS) must be used after this log exceeds 2 GB.
Other than the transaction logs, the remaining sources of disk I/O on Microsoft Exchange Server are generally random in nature. This includes the Windows NT page file, server databases, message tracking logs, and so on. The number of disk I/Os issued by the different parts of the system will vary over time while different server components do their work. For example, when a message is received from another server and delivered to a user, the MTA first secures the message to disk in its transient database, which causes a single random write to the MTADATA directory. It then makes a call to the system attendant, which writes a log entry into the message tracking log. Finally, the MTA then notifies the information store that a message is available, at which time the information store receives a message from the MTA and writes the message into a permanent database. This generates synchronous write I/O to the information store transaction log, and asynchronous read and write I/O to the information store database in the MDBDATA directory.
Because the source of these random server disk I/Os varies, you can combine the remaining disk drives into a software or hardware stripe-set, which enables the combined capacity of all the remaining disk drives in the system to be made available to any server component that is performing I/O.
You use a page file when the processes running on a Windows NT computer (including Windows NT itself) need more code and/or data pages over a period of time than there is physical memory in the computer.
If you have a lower-memory Microsoft Exchange Server computer, (for example, a computer with 24 MB and 50 to 100 users), some paging will occur on computers completing the normal set of Microsoft Exchange Server processes, such as handling user requests, moving mail off or onto a server, and so on.
Paging makes up a significant percentage of your total disk I/O because the working sets of all the Microsoft Exchange Server (and Windows NT Server) processes don't completely fit in physical memory all at once. Paging is a technique for implementing virtual memory. If the server is the only one in the site and off-server traffic is minimal, the MTA won't be doing much (except for expanding the occasional distribution list) and it will leave more room for the rest of the server processes, which results in less paging. Conversely, more paging will occur if you run additional processes on the same computer (beyond the core Microsoft Exchange Server services such as the Internet Mail Service), or if you import directory objects, generate the Offline Address Book, start up the server services, or do anything else that is non-typical.
If you have enough memory in your Microsoft Exchange Server computer such that the majority of the pages needed by all server processes fit into physical memory at the same time, you won't page very much during normal operation. Remember, however, that the working set of the information store and the directory store includes the buffer caches. Even on larger computers with 128 MB or more of RAM, you can page with very little activity if the buffer caches are set too high for the amount of RAM in the computer.
It is not recommended to dedicate a disk just to the page file because if you are paging, you will achieve better I/O performance by combining that drive into the stripe set and placing the page file there. If you aren't paging, it wastes drive space. It's best to stripe drives together to handle large databases because they are large, single files. You probably won't have many separate partitions over which to spread the page file, so placing it on the stripe set achieves the same result.