共用方式為

Jetstress uses Exchange 2003 SP1 ESE Performance counters for NAS storage sub-system.

  • 發行項

Jetstress enables "Use storage volumes on NAS" when you Exchange 2003 SP1 ESE binaries (of which must be later than or equal to 6.5.7104.0)

Drive letters used for the storage of Exchange 2003 database and log files are not presented as physical or logical disks; instead, they are presented as drive letters associated with a network file share. To measure performance of your network-attached storage system, you can enable the extended ESE performance counters available in Exchange 2003 Service Pack 1 (SP1) and later.

References:

This posting is provided "AS IS" with no warranties, and confers no rights.

Comments

  • Anonymous
    August 23, 2006
    Dear Admin:

    In the last few months, I had used JetStress to evaluate the potential of Exchange server 2003 before deploying it. Besides, my primary target is seeking test MBPS results on SAN enclosures which store (Exchange) databases.

    May I ask you question(s)?

    The results were always IOPS = MBPS. I wonder in JetstressUI, which parameters I can reset, e.g. change data size, to make multiple test results that would have different IOPS and MBPS? I am not quite sure about how to reconfigure all the parameters. I tried couple of times before, but JetStress would not run. So, I had to go back to default settings.

    Please advise. Thanks.
  • Anonymous
    August 24, 2006
    If you suppress tuning and enter test IO parameters with a less number of threads, you will have less IOPS (as well as less mega bytes per seconds).

    In the next version of JetStress (JetStress 2007), I'm thinking of providing the user with a fine control on IOPS or MBPS. For example, this feature will allow the user to excercise 75% of maximum throughput of the disk subsystem --- To be decided.

    Any feedback would be appreciated.
  • Anonymous
    August 25, 2006
    Hi hmlee,

    Thanks a lot for your prompt response.

    Since there is no way for me to tune the Jetstress to differentiate IOPS and MBPS settings, on one of my real-time Exchange 2003 servers, can I use Exchange counters in the Performance Monitor to generate IOPS and MBPS readings to establish the baseline?

    If it is feasible, which counters I can use to do that? What is the appropriate time interval to log them? Is any way I can transfer the readings to Excel so that I can plot graph? Please advise. Thanks in advanced.

    KC Yang

  • Anonymous
    August 28, 2006
    To establish the baseline, you may want to use Logical Disk performance counters (or, Database ==> Instances counters).

    If you have Exchange databases on NAS (network attached storage) and don't have logical disk counters available, you will have to use "I/O Database Reads/sec", "I/O Database Writes/sec", "I/O Log Reads/sec", and "I/O Log Writes/sec".

    If you have 3000 reads/sec and 2000 writes/sec on entire database disks, you have 5000 IOPS.

    It seems to me that 2 hours of logging would be enough to determine the disk sub-system's performance that we would use as the default for JetStress.

    You may want to manually transfer meaningful numbers from PerfMon.msc to Excel to make your own test report whether it's like a JetStress test report or not.

    Reference:
    http://www.microsoft.com/technet/prodtechnol/exchange/guides/E2k3Perf_ScalGuide/ccec1c70-a3df-404a-93e0-b74077e3d013.mspx
  • Anonymous
    September 13, 2006
    Hello,

    I have seen strange behavior using different versions of the JetStress UI including the latest version and I was hoping you could shed some light on the potential root cause.  

    It seems to happen more frequently during 6 hour TUNING tests, whereby during the last 15 minutes or so when the JetStress application is shutting down that I see enormous spikes for DB and LOG drive latencies.  To put in perspective, DB and LOG drive latencies are near-perfect (no spikes over .012) until this last 15 minutes (with spike well over .50)which of course results in a failure.  We have typically discounted the last 15 minutes or thereabouts for these tests as they do not occur all the time.  Do you know what actually causes this issue?  Is it merely the instances stopping?  Your help is greatly appreciated, thanks.

    Garion
  • Anonymous
    September 13, 2006
    Jetstress has to flush all dirty pages from the database cache prior to its shutting down. This causes a huge number of database writes which often causes hugh database write latency spikes.

    Jetstress performance log file (.blg) stops updating the log and then starts shutting down databases. Jetstress report will not have such spikes from flushing dirty pages.

    If you use Perf' Monitor, you should ignore the same portion. Please add refactorme@hotmail.com to your messenger contact if you like to have a chat w/ me.
  • Anonymous
    September 14, 2006
    Thank you for your prompt response, Mr. Lee.  I have taken you up on your offer as I do have additional questions.  Thanks again, and keep up the excellent progress with JetStress.

    Garion