성능 비교를 실행하기 전에 캐시를 지우는 SQL Server 명령

46

서로 다른 두 쿼리의 실행 시간을 비교할 때 첫 번째 쿼리의 실행이 두 번째 쿼리의 성능을 변경하지 않도록 캐시를 지우는 것이 중요합니다.

Google 검색에서 다음 명령을 찾을 수 있습니다.

DBCC FREESYSTEMCACHE
DBCC FREESESSIONCACHE
DBCC FREEPROCCACHE

사실, 내 쿼리는 이전보다 여러 번 실행 한 후에보다 현실적인 시간이 걸립니다. 그러나 이것이 권장되는 기술인지 확실하지 않습니다.

가장 좋은 방법은 무엇입니까?

sql-server performance-testing

— 안드레아
소스

43

개인적으로 일반적인 쿼리의 경우 두 번째 및 후속 실행이 더 중요합니다.

디스크 IO 또는 쿼리 성능을 테스트하고 있습니까?

쿼리가 자주 실행되고 중요하다고 가정하면 실제 조건에서이를 측정하려고합니다. 그리고 당신은 매번 제품 서버 캐시를 지우고 싶지 않습니다 ...

하고 싶다면해도 돼:

DBCC DROPCLEANBUFFERS버퍼 풀에서 클린 (수정되지 않은) 페이지를 지 웁니다. 더티 페이지를 디스크로 먼저 플러시
하는 CHECKPOINT것으로 시작하십시오.
DBCC FLUSHPROCINDB 해당 데이터베이스에 대한 실행 계획을 지 웁니다.

(DBA.SE 참조)

SQL 프로파일 러를 사용하여 높은 페이지로드 시간 해결

— gbn
소스

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를 순진하게 실행하면 두 번째 페이지가 첫 번째 쿼리에 의해 캐시 되었기 때문에 두 번째가 훨씬 빠를 수 있습니다. 각 실행 전에 캐시를 지우면 균등하게 시작됩니다.

핫 캐시 성능을 테스트하려면 쿼리를 여러 번 실행하고 번갈아 가며 첫 두 번의 실행을 취소해야합니다. 결과를 평균화하십시오.

최악의 성능

핫 캐시에 대해서는 1 초가 걸리지 만 콜드 캐시에 대해서는 1 분이 걸리는 쿼리가 있다고 가정합니다. 메모리 내 쿼리를 20 % 느리게하지만 IO 바운드 쿼리를 20 % 빠르게 만드는 최적화는 큰 승리 일 수 있습니다. 정상적인 작업 중에는 정상적인 상황에서 추가 200ms를 감지하지 못하지만 쿼리가 디스크 대신 60 초 대신 48 초가 걸리면 판매가 절약 될 수 있습니다.

이는 수십 기가 바이트의 메모리와 비교적 빠른 SAN 및 SSD 스토리지를 갖춘 최신 시스템에서는 문제가되지 않지만 여전히 중요합니다. 일부 분석가가 OLTP 데이터베이스에 대해 대량의 테이블 스캔 쿼리를 실행하여 버퍼 캐시의 절반을 지우면 스토리지 효율적인 쿼리를 통해 더 빠른 속도로 백업 할 수 있습니다.

— 모든 거래의 존
소스