MailBox Server Performance and System Memory
The Mailbox server role will likely have the biggest impact on performance of all the servers in Exchange Server 2010. Mailbox servers were traditionally very dependent on the disk subsystem for their performance. In
Exchange Server 2010, however, this has changed somewhat and the disk behavior is very related to the system memory. As a result, the primary rule for performance of an Exchange Server 2010 Mailbox server is to configure it with as much memory as you possible. As an example, in Exchange Server 2003, running a RAID 0+1 configuration and for a load of 2,000 users who generated an average of 1 disk I/O per second and you would require 4GB of memory and 40 disks (assuming a 10k RPM disk and 100 random disk I/O for each disk) to achieve the performance you would expect out of an Exchange server. For Exchange Server
2010, the I/O load per user would be approximately 0.15 disk I/O per second and you could therefore reduce the number of disks required by about 85% if you were to increase the system memory to 12GB. Thus with a mailbox server, the trick is to achieve a balance costs versus performance. For large implementations, it is less costly to replace high-performance disks with memory which makes direct attached disks a viable option for Exchange Server 2010 mailbox servers.
Mailbox Servers and The Disk Subsystem
Although the disk requirements for Exchange Server 2010 mailbox servers are lower than previous versions of Exchange Server, the disk subsystem is still an important consideration in performance tuning. Databases benefit the most using high-performance disks. Consider using 15k RPM drives which provide more I/O performance per disk – typically 50% more random I/O capacity compared to a 10k RPM disk. Given the reduction in disk required to support the databases, you should consider using RAID 0+1 as opposed to RAID 5 to avoid incurring the write penalties associated with RAID 5.
Log files also require fast disks to to commit information quickly, but have the advantage of being sequential I/O as opposed to random (therefore the write heads of the disk do not have to jump all over the disk to located the object to which they need to write). Logs always start at one point on a disk and write sequentially without having to modify old logs.
Exchange Server 2010 has implemented several changes which specifically improve performance when using SATA disks. Exchange Server 2010 has altered the I/O pattern and now disk writes are better spread out
and are less “bursty” than in previous versions. This means SATA disks are now a more viable choice for Exchange Server.
Another performance benefit with Exchange Server 2010 is the potential to entirely eliminate RAID. Database Availability Groups are being used with three or more replicas of mailbox databases, there is likely already sufficient redundancy in the system as a whole to eliminate the redundancy at the individual server level which RAID provides. Thus redundancy is provided at the application level as opposed to the server level. This is similar in many ways to the redundancy in Active Directory. In Active Directory,in the event a domain controller fails, it is usually not a major issue provided there are other DCs to assume the load. Instead of fixing a DC, we can simply build a new one and let it replicate the directory. In similar fashion, in Exchange Server 2010, if a DAG member fails, instead of restoring it, we can simply build a new one and let it replicate the data. Another DAG member will take over from the failed node and services would not be significantly impacted.
Ideally all databases and logs should be on their own dedicated disks. Although this is not always possible or practical, it provides the best performance since read/write patterns for databases and logs are very different. Keeping databases and logs on separate disks also makes recovery much easier.
Mailbox Servers and The Network
Mailbox servers handle large amounts of network traffic. Email messages are usually small and as a consequence, the transmission of these messages is not always efficient. If possible, equip mailbox servers with Gigabit Ethernet interfaces and if you are not clustering the mailbox servers run the network interfaces in a teamed mode. Thiswill improve both the performance and reliability.
Mailbox Servers and Public Folders
Since mailbox servers also hold the public folder stores, you should consider running a dedicated public folder server if the environment heavily leverages public folders. Public folder servers regularly store very large files which users access, therefore separating the load of large files from the mailbox servers will result in improved overall performance for the users.
In the event that public folders are only lightly used, it may require some investigation of the environment to determine if it is optimal to run a centralized public folder server or else maintain replicas of the public folders in multiple locations.