Share via

Best Practices, Hints and Tips Running JetStress 2007

  • Article

Many thanks to Mark Sewell for this information.

Experience from the field has shown that the following best practices, hints and tips are useful in using JetStress to determine appropriate requirements and configuration. The download location for JetStress and other tools for Exchange 2007 can be found on this page: https://technet.microsoft.com/en-us/exchange/bb330849.aspx.

  1. Follow the installed and online JetStress documentation carefully, paying particular attention to the storage subsystem requirements and configuration. Any design for carving out LUNs will need to balance the requirements for performance, recovery time and administrative costs (complexity). Use the Storage Requirements calculator provided:
  2. Storage Calculator assumes IOPS values for 80% disk capacity. Latest version makes this explicit. Performance will be less for stripes towards the spindle.
  3. Ensure multipathing is in use, if at all possible, in preference to Active-Passive/Concurrent or static routes through the SAN fabric. Check that the multipath software has an active licence if required. Have the customer engage the storage vendor to ensure that there are no bottlenecks through the SAN fabric. There are different algorithms available for multipathing and the vendor can determine which is best for load balancing in the customer's environment.
  4. The StorPort driver, introduced in Windows Server 2003, is much preferred over the older iSCSI and can deliver significantly better performance in hardware RAID and SAN environments.
  5. Remove anti-virus software and all other non-essential applications, as far as is practical, so that you can take a baseline of JetStress performance. Then you can incrementally add back in required applications and see their effect on JetStress. It is not sufficient to simply disable AV software as the filter drivers will still be in place and could still block or delay file I/O. Management or monitoring software could cause a conflict. Hardware vendors who assist customers in setting up their environment often install such management or monitoring suites. The customer's own OS support team may also install these applications.
  6. Also remove any third-party video drivers and verify that only the default VGA driver is installed (which can save a significant number of System PTEs) or use the /BASEVIDEO boot.ini switch.
  7. JetStress threads are applied on a per storage group basis. The more storage groups you have, the more I/O you will have with a constant thread count. Use autotuning initially to arrive at an approximate thread count and then fine tune manually to hit the target IOPS for a given number of storage groups. Setting a fixed thread count is not going to provide an exact IOPS value but we are aiming for the actual IOPS to be within 5% of the target. Start with fewer threads and increase them over different tests, using the JetStress reports and Performance Monitor data to confirm that the server and storage are handling the target load. In this way you should arrive at an optimal thread count tuning that provides the best basis consistent JetStress results.
  8. Need to view the report in conjunction with the Performance Monitor logs in order to determine that the I/O JetStress is generating is as expected (in terms of I/O sizes, ratios, burstiness, etc.). For example, performance graphs ramping up with time have been seen when using AMD Opteron servers. These turned out to be a missing boot.ini file /usepmtimer switch as per https://support.microsoft.com/kb/895980.

One addition the IO generation in JetStress is linked to the SGs due to the way the IO generation works in the tool. So if you need to add more threads this will generate more IO and spread it over the SGs. It does not mean that the tool gives you the amount of SGs you need! The more SGs you have the better in the Real World!