Troubleshooting Jetstress 2010
Applies to: Exchange Server 2010 SP1, Exchange Server 2010
Topic Last Modified: 2012-07-23
While using Jetstress, you may encounter some known issues. This topic provides information about causes and recommended solutions.
This issue can occur when you're using Microsoft Exchange Server 2007 Extensible Storage Engine (ESE) files and you attempt to store multiple log streams on the same logical disk volume. Although this is a valid Exchange Server deployment, Jetstress uses the logical disk counters to record I/O latency values for each database and log stream. If multiple databases and logs are using the same logical disk, Jetstress is unable to isolate the performance counters required.
To work around this issue, edit the JetstressConfig.XML file and change the value of the useEseCounters parameter to
Save the XML file, and then attempt to re-configure the test with overlapped files. Jetstress will now allow the configuration, because it has been configured to use the I/O performance data from ESE rather than the operating system logical disk counters.
Event log error that may display: Error -1023
Possible cause The path of the database or log files is incorrect.
Solution Ensure that the paths and file names are correct.
Event log error that may display: Error -1032
Possible cause Permissions are insufficient to access the .edb file or the log files.
Solution Verify that permissions are sufficient for the account under which Jetstress is running. Jetstress requires read/write permission to the directories it's using.
Event log error that may display: Error -550 (0)
Possible cause The last time Jetstress was run, it was ended in such a way that the log files became unsynchronized with the database.
Solution Delete the Jetstress database (*.edb), log files (*.log), and check file (*.chk), and re-create the Jetstress database. You can also use Eseutil.exe with the /r switch to resynchronize the logs and database.
Event log error that may display: Error -1022
Possible cause The failure is caused by circular logging by Jetstress.
Solution Check the log drive for the log file name identified in the event log. Delete that log file and all the log files that have a higher number in the file name. Then, run Eseutil.exe /r to recover Jetstress.edb. When the database is in a good state, delete all the log files in the log directory, and rerun Jetstress.
JetstressWin.exe relies on performance counters to monitor the system. JetstressWin.exe requires the Extensible Storage Engine (ESE) database counters to be installed.
Cause When the counters aren't loaded correctly, you may see exception errors related to performance counters.
Solution To reload the counters, exit from JetstressWin.exe. Locate the directory where JetstressWin.exe was installed and verify that eseperf.dll, eseperf.hxx, and eseperf.ini files exist in the directory. In a command shell window, type the command unlodctr ESE, and then click Enter. This will unregister the ESE database performance counters. Start JetstressWin.exe and allow it to reload the performance counters.
Uninstalling Jetstress causes performance counter issues.
Cause In certain cases when Exchange was installed before Jetstress, uninstalling Jetstress could result in unstable database performance counters.
Solution To restore access to database counters after Jetstress has been removed, go to the Exchange installation directory (for example, D:\*\Exchange Server\V14\bin) from a command prompt.
From the command prompt, type the command unlodctr ESE to ensure that the database performance counter registration information has been completely removed from the registry.
Type the command lodctr esperf.ini, which should correctly register the database counters.
- From the command prompt, type the command unlodctr ESE to ensure that the database performance counter registration information has been completely removed from the registry.
The database performance counters will now be available.
This error indicates that Jetstress couldn't find appropriate parameters that could be used to run a performance or stress test at the desired level of input/output (I/O) load.
Cause This can be caused by several factors. The most common reason is that the storage subsystem has multiple hosts attached to it, and those hosts are competing for common resources during the tuning process.
Solution When you're running in a scenario such as this, you can run Jetstress on a single host with tuning enabled to generate the appropriate load parameters, and then rerun the test on the other hosts with the Suppress tuning and use thread count option enabled and the tuning parameters entered manually from the results of the first test.