Exchange Jetstress - Determine maximum disk subsystem throughput

Jetstress is an important Exchange tool that should be run on all Mailbox Role servers before Exchange is installed. Proper tuning of Jetstress will help you determine maximum disk subsystem throughput performance.

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

Jetstress - Define Test Scenario

Let’s take a example:

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

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.

ThreadsLog Disk Writes/secDB Disk Transfers/secTotal
133107140
263195258
3105308413
4150400550
5190535725
1039010501440
2050019002400

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.

Want to write for 4sysops? We are looking for new authors.

Read 4sysops without ads and for free by becoming a member!

0
Share
6 Comments
  1. gointern 7 years ago

    Is SATA 7200 RPM good enough for exchange? I am looking to get a new server and thinking between SAS 15K or SATA.

    0

  2. vipin 7 years ago

    The higher the thread count, the more the transactional operations are performed. What do u think?

    0

  3. gointern 7 years ago

    Faster are better

    0

  4. Author
    krishna 7 years ago

    Hi Gointern,

    Exchange 2010 DAG offers 16 copy of same database. It will be very expensive to go for SAS disk if you are planning for multiple copies. SAD disk are definitly better performance then SATA disk with it does not offers much space. Based on your budget and requirement you can plan for either SAS or SATA disk.

    Vipin, thats correct. Higher the thread count more transactional operations are performed. Intercrease of thread count can determine the performace atchived on the disk

    Regards,
    Krishna

    0

  5. Kasal 1 year ago

    is there any limitation of increasing thread count?

    OPS provided per thread should match the disk availed IOPS. Please suggest.

    0

  6. Tony Brock 6 months ago

    It isn't a specific drive type you should be considering necessarily, it is whether or not the drive/array of drives you've chosen can properly handle the IOPS requirement particular to you environment and user profile(s). I would recommend starting with the latest Exchange Calculator to help you properly determine this requirement.

    0

Leave a reply

Your email address will not be published. Required fields are marked *

*

© 4sysops 2006 - 2020

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account