 |
|
SQL Product Highlight
SQL Sentry, Inc. - SQL Sentry Performance Advisor
SQL Sentry Performance Advisor for SQL Server delivers an advanced performance dashboard with relevant Windows and SQL Server metrics in a single view along with detailed insight of heavy SQL, blocking, deadlocks, and disk bottlenecks. Performance Advisor is packed with ground-breaking features that are not found in any other performance monitoring software, all designed with the singular goal of simplifying the process of optimizing your SQL Server performance.Learn more!
Clearing Cache for SQL Server Performance Testing
|
By: Jeremy Kadlec | Read Comments (3) | Related Tips: More > Testing |
Problem
When conducting performance testing and tuning on a new system, most of the time a number of options are outlined to potentially correct the performance problem. To determine the best overall solution, each option is tested and the results are recorded. As lessons are learned options may be combine for a better end result and often as data is cached the overall query performance improves. Unfortunately, with the data in cache testing each subsequent option may lend itself to an apples to oranges comparison. How can I ensure during each execution of a new set of code that the data is not cached?
Solution
If all of the performance testing is conducted in SQL Server the best approach may be to issue a CHECKPOINT and then issue the DBCC DROPCLEANBUFFERS command. Although the CHECKPOINT process is an automatic internal system process in SQL Server and occurs on a regular basis, it is important to issue this command to write all of the dirty pages for the current database to disk and clean the buffers. Then the DBCC DROPCLEANBUFFERS command can be executed to remove all buffers from the buffer pool. Here is a quick code snippet to serve as an example:
| USE <YOURDATABASENAME>; GO CHECKPOINT; GO DBCC DROPCLEANBUFFERS; GO |
Although the CHECKPOINT and DBCC DROPCLEANBUFFERS commands seem to be the most elegant approach because they can be included in your T-SQL test scripts, you also can achieve the same results by either restarting the SQL Server instance or restarting Windows. If you are testing via a batch file (or similar) then you could issue 'net stop mssqlserver' and 'net start mssqlserver' DOS commands. As a side note, you also have the option to shutdown SQL Server via the T-SQL SHUTDOWN command, but would need to restart the services via either the 'net start' command or via one of the GUI tools. Although these options are possible, they are not recommended. These last set of commands will shut down your SQL Server instance or machine, which is probably unneeded.
A few words of caution...
It is not recommended to issue the CHECKPOINT\DBCC DROPCLEANBUFFERS, the 'net stop mssqlserver', T-SQL SHUTDOWN command or restarting Windows on production systems just for the sake of testing. These commands could have detrimental results to your environment. It is recommended to only issue these types of commands in testing environments with coordination among your team due to the impact to the overall SQL Server. In addition, keep in mind that if you do issue these commands only in test environments that if multiple tests are being conducted simultaneously issuing the CHECKPOINT and DBCC DROPCLEANBUFFERS commands may skew results for other testers.
Next Steps
- As you conduct performance testing in the future consider including the CHECKPOINT and DBCC DROPCLEANBUFFERS command in each of your scripts to ensure cached data is not benefiting later executions of your code.
- As you test, it may be a good idea to capture the query execution results for cold and warm cache.
- Although, time needed for a query is important, it is also a good idea to review the query plans for the code to determine the best cost among the options.
- For related information check out the following:
Last Update: 10/26/2007
About the author
View all my tips
Print
Comments and Feedback:
| Tuesday, October 30, 2007 - 1:02:50 AM - Bharathy | Read The Tip |
|
Generally in the production environment users will access the database concurrently, so the ‘datacache' could holds the data for the repeatedly called SQLs. In the same way, if the load testing run is trying to simulate the production scenario / usage, then the explicit call to clear the data cache could simulate the worst case scenario of the application usage rather than the real time requirement. Even for the query tuning, better execute the SQL, at least for 3 to 4 times, and get the final statistics like query execution time (elapsed time), physical reads, logical reads, sorting & etc and tune it to reduced the these values. So, clearing the ‘datacahce' is not valid for performance testing.
|
|
| Saturday, November 03, 2007 - 10:24:06 AM - admin | Read The Tip |
|
Bharathy, Thank you for the feedback on the tip. In the scenario where our team used the script (CHECKPOINT and DBCC DROPCLEANBUFFERS) outlined in this tip and found value was in these testing scenarios:
Due to the significance of the changes, we wanted to be able to start each test run at the same point (all data committed with cleared cache) as all of the other tests to ensure we could observed the metrics with both cold and warm cache. Thank you, |
|
| Thursday, April 15, 2010 - 10:49:47 AM - Repriser2010 | Read The Tip |
|
Also, try to differentiate your are testing "recompile" or not. Never "test" on production environment. "Tune" on production environment after test on QA environment. |
|
|
privacy | disclaimer | copyright | advertise | about authors | contribute | feedback | giveaways | user groups Some names and products listed are the registered trademarks of their respective owners. Edgewood Solutions LLC | MSSharePointTips.com | MSSQLTips.com |