Команди SQL Server для очищення кеш-пам'ять перед початком порівняння продуктивності

46

Порівнюючи час виконання двох різних запитів, важливо очистити кеш, щоб переконатися, що виконання першого запиту не змінює продуктивність другого.

У пошуку Google я міг знайти такі команди:

DBCC FREESYSTEMCACHE
DBCC FREESESSIONCACHE
DBCC FREEPROCCACHE

Насправді мої запити потребують більш реалістичного часу, щоб виконати декілька виконань, ніж раніше. Однак я не впевнений, що це рекомендована методика.

Яка найкраща практика?

sql-server performance-testing

— andrerpena
джерело

44

Особисто для загального запиту важливіше 2-е та наступні страти.

Ви тестуєте IO диска чи продуктивність запитів?

Якщо припустити, що ваш запит працює часто і є критичним, то ви хочете виміряти це в реальних умовах життя. І ви не хочете щоразу очищати кеші prod сервера ...

Якщо ви хочете, ви можете:

DBCC DROPCLEANBUFFERSочищає чисті (немодифіковані) сторінки з буферного пулу.
Попередньо, щоб зі CHECKPOINTспочатку видалити будь-які брудні сторінки на диск
DBCC FLUSHPROCINDB очищає плани виконання цієї бази даних

Також дивіться (на DBA.SE)

Вирішення високого часу завантаження сторінки за допомогою SQL Profiler

— гбн
джерело

3

Отримала помилку під час запуску DBCC FLUSHPROCINDB: для оператора DBCC було задано неправильну кількість параметрів.

— Сінь

Нарешті знайшов це: DECLARE @myDb AS INT = DB_ID(); DBCC FLUSHPROCINDB(@myDb); GOзвідси: stackoverflow.com/questions/7962789/…

— Ганс Вонн

14

Пізня відповідь, але може бути корисною для інших читачів

DBCC DROPCLEANBUFFERS - це часто використовувана команда для тестування запитів та вимірювання швидкості виконання запитів. Ця команда (при виконанні) залишає після себе лише брудні сторінки, що є фактично невеликою частиною даних. Він видаляє всі чисті сторінки для всього сервера.

Зауважте, що ця команда не повинна виконуватися у виробничих умовах. Запуск цієї команди призведе до переважно порожнього кеш-пам'яті. Запускаючи будь-який запит після виконання команди DBCC DROPCLEANBUFFERS, використовуватимуть фізичні читання для повернення даних у кеш, що, швидше за все, буде набагато повільніше, ніж пам'ять.

Знову ж, поводьтеся з цією командою аналогічно DBCC FREEPROCCACHE - її не слід запускати на будь-якому виробничому сервері, якщо ви абсолютно не знаєте, що ви робите.

Це може бути корисним інструментом розробки, оскільки ви можете запускати запит у середовищі тестування продуктивності знову і знову без будь-яких змін швидкості / ефективності через кешування даних у пам'яті.

Докладніше на: http://www.sqlshack.com/insight-into-the-sql-server-buffer-cache/

— Томас Бові
джерело

9

Мені завжди казали використовувати:

dbcc dropcleanbuffers;

Від MSDN :

Використовуйте DBCC DROPCLEANBUFFERS для тестування запитів із кешем холодного буфера без вимкнення та перезавантаження сервера.

Щоб випустити чисті буфери з буферного пулу, спочатку використовуйте CHECKPOINT для створення холодного буфера кешу. Це змушує всі брудні сторінки для поточної бази даних записуватися на диск і очищає буфери. Після цього ви можете видати команду DBCC DROPCLEANBUFFERS для видалення всіх буферів з буферного пулу.

— DaveShaw
джерело

2

Плюс: DBCC FREEPROCCACHEочистити будь-які плани кешованого виконання ...

— marc_s

1

Тільки якщо ви хочете перевірити IO, неодмінно ...

— gbn

3

Інші відповіді правильні щодо причин не бігти DBCC FREEPROCCACHE. Однак є також кілька причин:

Послідовність

Якщо ви хочете порівняти два різні запити чи процедури, які намагаються зробити те саме по-різному, вони, ймовірно, потрапляють на одні і ті ж сторінки. Якщо ви наївно запускаєте запит №1, то запит №2, другий може бути набагато швидшим, просто тому, що ці сторінки були кешовані першим запитом. Якщо очистити кеш-пам'ять перед кожним виконанням, вони починаються рівномірно.

Якщо ви хочете перевірити продуктивність гарячого кешу, не забудьте виконати запити кілька разів, чергуючи та відмовтеся від перших кількох запусків. Середні результати.

Найгірші показники

Скажімо, у вас є запит, який займає одну секунду проти гарячого кешу, але одну хвилину проти холодного кешу. Оптимізація, яка робить запит в пам'яті на 20% повільніше, але запит, пов'язаний з IO, на 20% швидше, може стати великим виграшем: під час звичайних операцій ніхто не помітить зайвих 200 мс за звичайних обставин, але якщо щось змусить запит запустити диск, зайняття 48 секунд замість 60 може зберегти продаж.

Це менше турбує сучасні системи з десятками гігабайт пам'яті та відносно швидким зберіганням SAN та SSD, але це все одно має значення. Якщо якийсь аналітик виконує запит масового сканування таблиці щодо вашої бази даних OLTP, який видаляє половину кеш-пам’яті, запити з ефективними сховищами швидше відновлять вас.

— Джон усіх торгів
джерело