Exchange 2007 Service Pack 1 introduces several changes in the Extensible Storage Engine (ESE). In my first blog article on the subject, I discussed the removal of page dependencies and the disabling of partial merges. I discuss other changes we made to ESE which enhance Exchange.
- Passive Node I/O improvements
- Online Defragmentation
- Checksumming databases
- Page Zeroing
Passive Node I/O Improvements
When we released Exchange 2007, the I/O generated on the passive node in a CCR environment was ~2-3 times the I/O generated on the active node. For example, consider a server which contains 3500 very heavy profile mailboxes. The active node generated about 1300 IOPS, while the passive node generated about 3500 IOPS, even though the only activity occurring on the passive node is log inspection and replay!
The extra I/O on the passive node was the result of the design of the replay function. In RTM, when log replay starts on the passive node, an instance of ESE is started and used to replay the replicated logs. During this replay activity, pages are read from the database, which in turn populates the ESE database cache. When log replay has finished, the Replication Services stops and discards the database instance, thereby deleting database cache that was built up during the replay process. As a result, we see spikes in activity. When log replay is not behind, the cache will continually be small, and thus more read I/Os will occur against the passive node's disks. When log replay gets behind, the instance of ESE will remain active longer, and we obtain a larger database cache, which decreases read I/Os.
By itself, the additional disk I/O on the passive node is not a problem. But there are two scenarios where this additional I/O can have a significant impact - backups and storage design. Consider the scenario where you are performing VSS backups on the passive node. The additional disk I/O on the passive node can interfere with your ability to take a backup during the core user activity window, thus forcing you to schedule backups at off-hours. This negates the advantage of being able to backup storage groups on the passive node.