The conversation between Bob Dorr and Jose Fortuny also yielded some additional insights in the following discussion.  Keep in mind that Bob and Jose were discussing very specific results from a specific test run and test environment.  However, the conversation provides several useful tips. 

 

First, notice that the ALLOWIOBURSTS setting can overwhelm certain drivers.  Bob also gives us a good pointer about the test steps “Performing Full Test Iteration” and the following step “Performing Final Checkpoint #1”.  And finally, the paragraph about “Final Audit Scan” provides some good background and context information for better understanding of this step in the SQLIOSIM processing.

 

Thanks again to Bob and Jose.  To see Bob Dorr’s earlier post, refer to http://blogs.msdn.com/psssql/archive/2008/11/12/how-it-works-sqliosim-running-average-target-duration-discarded-buffers.aspx.

 

Thanks,

 

-Kevin

 

~~~

 

- Is it possible that your hardware cache could hold 8GB of data?

 

You are using the default for max and 2 files according to the configuration.   The largest file size of 8GB starting at 4GB.     MaxOutstandingIO=0

 

MaxOutstandingIO: is limited as outlined in the KB article and when set to 0 dynamically set to the max to allow all out IO stress.

 

You have AllowIoBursts = Yes.   This is a great test and we have seen some drivers that are low on non-paged memory or similar resource blue screen machine.   

 

A number of throttled requests usually stems from the fact that at certain points of the test throttling is disabled which results in posting of thousands of simultaneous requests.

The AllowBursts is on by default and designed that way. It allows the checkpoint phase to lift any I/O latency restrictions and post 1000s of I/Os.  

 

08/19/08

06:58:26

740

System

Starting test cycle

CSQLIOSimView::OnWndMsg

e:\yukon\sosbranch\sql\ntdbms\storeng\util\sqliosim\sqliosimview.cpp

238

 

08/19/08

06:58:26

3124

System

Created buffer pool. Size=2713 MB, buffers 347264, locked pages disabled.

CBufferPool::hrCreateBufferPool

e:\yukon\sosbranch\sql\ntdbms\storeng\util\sqliosim\buffer.cpp

1205

 

08/19/08

06:58:28

1032

Overall Test Progress

Performing initial Update Scan

CTestCycle::EntryPoint

e:\yukon\sosbranch\sql\ntdbms\storeng\util\sqliosim\testusers.cpp

1855

 

08/19/08

06:58:54

1032

Overall Test Progress

Checkpointing initial Update Scan

CTestCycle::EntryPoint

e:\yukon\sosbranch\sql\ntdbms\storeng\util\sqliosim\testusers.cpp

1861

 

08/19/08

06:59:25

1032

Overall Test Progress

Performing Full Test iteration #1

CTestCycle::EntryPoint

e:\yukon\sosbranch\sql\ntdbms\storeng\util\sqliosim\testusers.cpp

1873

 

08/19/08

07:04:26

1032

Overall Test Progress

Performing final Checkpoint #1

CTestCycle::EntryPoint

e:\yukon\sosbranch\sql\ntdbms\storeng\util\sqliosim\testusers.cpp

1886

 

08/19/08

07:04:27

1032

Overall Test Progress

Performing final Audit Scan #1

CTestCycle::EntryPoint

e:\yukon\sosbranch\sql\ntdbms\storeng\util\sqliosim\testusers.cpp

1896

 

08/19/08

07:04:56

740

System

Test cycle complete

     

 

Performing Full Test iteration:  After 'Performing Full Test iteration' message we look at the allow burst parameter.   If yes we disable the throttling and execute the checkpoint.   Once checkpoint is complete we enable throttling again and we loop around and start the next iteration.  Turning on the throttling uses the configured TargetIODuration and turning it off used a MAX_DWORD value.   In your configuration file this is TargetIODuration=100

 

Final Audit Scan: Creates 4 * the number of CPUs being used workers to perform the scan and central class that hands out the next page(s) to audit.   They all go after the information to complete the scan.  Each audit user worker gets the next extent, setups a request and asks the SQLIOSim BPool to return the buffers.   This reads the page(s) from disk and does the audit I described in the previous portion of this e-mail.   We post the read for ## of buffers, then we wait for the read to complete.   The completion handles the audit actions and we go around the audit loop for the next extent.  In general we are not going to push all that agressivly during the audit phase.     On this server it is a 2 CPU machine so we will have 8 workers issuing a read, auditing some pages and going around the loop.   We likely are getting back good IO times so we don't have to push the level of IO request blocks above 45 and because the IOs are completing quickly the average dips below 10ms and is displayed as 0.