Latest posts by Krishna Kumar (see all)
- Review of Stellar Phoenix Mailbox Exchange Recovery - Wed, Jul 22 2015
- Configure Exchange 2013 Internet mail flow during migration - Fri, Dec 27 2013
- Exchange 2013 DAG recovery in a stretched AD site - Part 2 - Wed, Dec 25 2013
The disk subsystem is a very important design factor—as important as memory or CPU. Improper sizing can lead to a serious performance impact for end users. Disk sizing does not just mean sizing the disk for capacity; it also includes calculation of IOPS, or input/output operations per second performed on the disk subsystem. Exchange 2010 has changed the database architecture from having random IOPS to sequential ones. This architecture change has greatly reduced the IOPS utilization on disk. The higher the disk capacity, the lower the disk speed and disk IOPS performance are. Similarly, the lower the disk capacity, the higher the disk speed and disk IOPS performance are.
Below is the reference snapshot of selecting the Jetstress option to test the disk subsystem throughput.
Jetstress - Define Test Scenario
Let’s take a example:
Disk Subsystem : SATA 2 TB
Disk Raid : JBOD (Raid 0)
Database per Disk : 1 DB/Disk
Disk Speed : 7200 RPM
Expected IOPS : ~75 IOPS
Heavy User : 250 mails send/receive per day
User IOPS : 0.30 (based on the Exchange storage calculator
for heavy users)
Based on the design calculation of 75 IOPS per disk, we can have around 214 users per disk. It would be ideal if we could get the expected IOPS as per the design. Actual performance may vary for different hardware vendors. To make sure that we have the right design to meet our requirement, we need to perform Jetstress tests on the disk system to determine the maximum throughput performance.
Jetstress can be executed in auto tuning mode or in manual tuning mode by providing a different thread count parameter. Thread count determines the number of transactional threads per database. Transactional threads include insert (40%), read (35%), update (5%), and delete (20%). Auto tuning, which automatically determines the maximum thread count that the storage can support, is not the ideal way to determine the disk throughput.
It is always recommended to perform manual tuning to get more accurate results. Manual tuning is performed by selecting the option “Suppress tuning and use thread count (per database)” and passing the thread count value. Below is the reference snapshot of the same where the thread count is set to 2.
Jetstress - Select Capacity and Throughput
The higher the thread count, the more the transactional operations are performed. Below is the thread count with different transactional operations per second.
|Threads||Log Disk Writes/sec||DB Disk Transfers/sec||Total|
Execute Jetstress for smaller windows, say 2 hours, and use the attached existing DB that was created during the first run. Keep increasing the thread count by 1 for every consecutive Jetstress run until the Jetstress result fails. Note the “Achieved Transactional I/O per second” value on every successful Jetstress test result. Also make sure that “I/O Database Reads Average Latency” is less than 20 ms and “I/O Log Writes Average Latency” is less than 10 ms for each successful Jetstress. A successful Jetstress result would be the maximum disk throughput performance achieved on the specific disk subsystem.
“Achieved Transactional I/O per second” is the total numbers of transactional I/Os obtained from the server per second. (Achieved Transactional IOPS / user IOPS) gives you the maximum number of users that can be hosted on the server. This number should match your design. You may need to tweak your design if the test results and the design do not match.
I hope you are now clear on how to find the maximum disk subsystem throughput performance and how to match this value with your design.