Команды SQL Server для очистки кэшей перед выполнением сравнения производительности

46

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

В поиске Google я мог найти эти команды:

DBCC FREESYSTEMCACHE
DBCC FREESESSIONCACHE
DBCC FREEPROCCACHE

На самом деле, мои запросы занимают более реалистичное время после нескольких выполнений, чем раньше. Однако я не уверен, что это рекомендуемая техника.

Какая лучшая практика?

sql-server performance-testing

— andrerpena
источник

44

Лично для общего запроса 2-е и последующие исполнения имеют большее значение.

Вы тестируете дисковый ввод-вывод или производительность запросов?

Если ваш запрос выполняется часто и является критическим, то вы хотите измерить его в реальных условиях. И вы не хотите очищать кэши Prod-сервера каждый раз ...

Если ты хочешь, ты можешь:

DBCC DROPCLEANBUFFERSочищает чистые (немодифицированные) страницы из пула буферов.
Предшествуйте этому с помощью a, CHECKPOINTчтобы сначала удалить любые грязные страницы на диск
DBCC FLUSHPROCINDB очищает планы выполнения для этой базы данных

Также см. (На DBA.SE)

Решение высокой загрузки страницы с помощью SQL Profiler

— ГБН
источник

3

DBCC FLUSHPROCINDBПроизошла ошибка при запуске : неверное число параметров было указано в инструкции DBCC.

— Xin

Наконец нашел его: 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% медленнее, но связанный с вводом-выводом запрос на 20% быстрее, может быть большим выигрышем: при обычных операциях никто не заметит дополнительные 200 мс при нормальных обстоятельствах, но если что-то заставляет запрос запустить против диска, 48 секунд вместо 60 может спасти продажу.

Это менее важно для современных систем с десятками гигабайт памяти и относительно быстрым хранилищем SAN и SSD, но это все еще имеет значение. Если какой-то аналитик выполнит запрос массивной таблицы на вашу базу данных OLTP, которая уничтожит половину вашего буферного кеша, эффективные для хранения запросы вернут вас быстрее.

— Джон на все руки
источник