Partager via

Jetstress: How Jet database operation mix works

  • Article

JetStressUI WinForm application takes Jet database operation mix, e.g. 17 inserts, 68 replaces, 5 deletes, and 90 lazy commits (those number are percentages and the rest 10% is for additionally seeking records since deletes and replaces also have seeks as part of them).

Then, it checks the following error and warning conditions:

  • Error: Sum of inserts, replaces, and deletes is greater than 100.
  • Error: Lazy commits is greater than 100.
  • Warning: Deletes is greater than 10 --- This high deletes can make Jet engine's version bucket grow out of bound.
  • Warning: Deletes is greater than Inserts --- This higher deletes than inserts will make data scarce in the database.

JetStressInterop (which is JetStress engine library) has the following Jet database operations:

  • Delete Records: JetSeek, and JetDelete
  • Replace Records: JetSeek, JetSetColumn, and JetUpdate
  • Insert Records: JetSetColumns, and JetUpdate
  • Seek Records: JetSeek
  • Lazy Commit: Use JetCommitTransaction(sesid, JET_bitCommitLazyFlush) after database operations.

If the user selected suppress tuning and used the default Jet database operation mix, JetStressInterop.log will have the following:

18:26:35 --- JetInteropRun with record size 1000
18:26:35 --- Thread0: 17% of operations will be inserts
18:26:35 --- Thread0: 68% of operations will be replaces
18:26:35 --- Thread0: 5% of operations will be deletes
18:26:35 --- Thread0: 10% of operations will be seeks --- [HMLee] This is 100% - (17% + 68% + 5%) .
18:26:35 --- Thread0: 90% of commits will be lazy --- [HMLee] 90% of the time, JetStress will useJetCommitTransaction (sesid, JET_bitCommitLazyFlush) .

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

Comments

  • Anonymous
    August 07, 2005
    Hello. Some interesting information here.

    Is there or will there be some more detailed information on Jetstress and it's parameters (especially how the tuning process arrives at these parameters?)

    Currently we're having an issue where Jetstress is using wildly different figures during it's autotuning process on consecutive runs (ie, it'll use 10 threads on one run for performance testing, then it'll use 1 thread on the next). This has resulted in wildly different figures.

    If we force Jetstress to use the same parameters every time the results are reproducible and consistent.

    Thanks
  • Anonymous
    August 08, 2005
    The comment has been removed
  • Anonymous
    August 08, 2005
    Thanks for the response.

    Forcing the parameters was what we did in the end which meant we got consistent results on concurrent runs of Jetstress.

    The question is though is then progress to changing the disk subsystem (adding an extra couple of spindles or changing the RAID level) and re-run won't the Jetstress parameters we used now be sub-optimal?

    I assumed the auto-tuning process is ESE 'figuring out' the best way to use the disks?

    The follow on question is that we're using Jetstress to find the optimal configuration for Exchange. The forced figures we are using may not be the ones Exchange will use (as we can't force the IS to use the Jetstress figures).

    I'll see if I can find any extra log files and data as well.

    Cheers again!
  • Anonymous
    August 08, 2005
    If there is any change to disk subsystem, you'd better delete JS_Config.xml (or the test parameter elements) and start from 'scratch' since the previous test parameters will mislead the automatic tuning job.

    The tuning just tries to achieve the planned number of I/O per second. If you want to figure out the best use of disk sub-system, you should try tuning multiple times from 'scratch'.

    There seem to me some misunderstanding about JetStress tool. JetStressUI doesn't try to match what Exchange really does. JetStress test parameters are only for the planned IOPS, not for Exchange configuration.