SQL Server 기준 테스트를위한 결정적인 단계 목록?


10

SQL Server를 사용하는 앱에 대한 성능 테스트 / 기준을 실행하기 전에 인스턴스를 다시 시작하지 않고도 인스턴스를 "깨끗한"상태로 설정할 수 있기를 원합니다. 따라야하는 단계가 있지만 올바른 순서이며 중복 단계가없는 결정적인 목록을 작성하려고합니다.

이 단계 목록이 SQL Server를 "깨끗한"상태로 설정합니까?

순서가 논리적 / 정확합니까?

중복 단계가 있습니까?

CHECKPOINT              -- Write all dirty pages

DBCC DROPCLEANBUFFERS   -- All should be clean after checkpoint?

DBCC FREEPROCCACHE      -- Clear the plan cache

DBCC FREESYSTEMCACHE    -- Is this necessary after FREEPROCCACHE?

DBCC FREESESSIONCACHE   -- May not be necessary if distributed queries aren't used, but want to catch all scenarios

EXEC SP_UPDATESTATS     -- Refresh stats

'BEGIN TESTING!'

5
참고 DROPCLEANBUFFERS로 테스트에는 적합하지만 항상 정확한 것은 아닙니다. 대용량 테이블을 참조하는 경우 거의 항상 메모리에 페이지가 있고 IO 시간은 해당 쿼리에 큰 영향을 미치지 않습니다. 이 경우 실제보다 IO에 더 많은 가중치를 부여 할 수 있습니다.
JNK

프로덕션 환경 또는 격리 된 테스트 환경에서의 테스트에 대해 이야기하고 있습니까?
bopapa_1979

Prod 환경에서 테스트하는 사람은 해고되어야합니다. :) 예, 테스트 환경.
Eric Higgins

답변:


5

먼저, 물러서서 테스트 중에 수집 할 측정 값을 묻습니다. 예를 들어 쿼리별로 논리적 읽기를 계산하는 경우 캐시를 비울 필요가 없습니다. 논리 읽기를 사용하는 데는 열렬한 팬입니다. 데이터가 캐시되는지 디스크에 있는지 여부와 무관하며 프로덕션 환경에서는 쿼리의 데이터가 캐시되는지 여부를 추측하기가 어렵습니다 (전체 데이터베이스를 메모리에 캐시하지 않는 한) . 논리적 읽기를 최소화하도록 조정하면 데이터가 캐시에 있는지 여부에 관계없이 앱이 더 빨라집니다.

다음으로 달리기 사이에 어떤 변화가 있는지에 대해 질문했습니다. 예를 들어, 제안한대로 각 데이터베이스에서 EXEC SP_UPDATESTATS를 실행하면 업데이트 된 테이블에 대한 통계를 다시 샘플링합니다. 그러나 fullscan으로 통계를 업데이트하지 않는 한 테이블에서 임의의 행을 가져옵니다. 이는 반복 할 수 없으며 실제로 그렇게하고 싶지는 않습니다. 대신, 항상 동일한 데이터를 테스트하기 위해 각 실행간에 데이터베이스를 복원 할 수 있습니다. 테스트에서 삽입 / 업데이트 / 삭제를 수행하는 경우 데이터베이스를 복원하지 않으면 (데이터 추가 / 변경, 데이터 통계 변경으로 인해) 각 실행마다 다른 성능 프로파일이있을 수 있습니다.


아주 좋은 점은 목표는 달리기 사이에 모든 것을 동일하게 유지하는 것입니다. 이 경우 @ hand에서 측정 한 값은 앱의 특정 기능에 대한 런타임입니다 (목록을 앱으로 반환하는 데 x 초, 대기열 항목을 추가하는 데 y 초 등). 테스트 사이에 변경되는 것은 SQL 코드가 아닌 앱 코드 조각, 앱 코드가 아닌 SQL 객체 또는 앱 코드가 변경되지 않은 동시성과 같은 인스턴스 / DB 레벨 설정 일 수 있습니다. 각 테스트 전에 게이트에서 복원을 추가하려는 경우 @ 지점 위의 내 목록에 대해 어떻게 생각하십니까? 누락 된 것이 있습니까, 아니면 순서가 필요합니까?
Eric Higgins

브렌트, 테스트에서 CPU를 고려하고 있습니까?
AK

@EricHiggins 한 번에 여러 가지를 테스트하는 대신 조각을 개별적으로 테스트합니다. 오히려 쿼리를 직접 테스트하고 어떤 변화가 성능에 영향을 미치는지 확인하고 싶습니다. 예를 들어 앱에서 특정 기능을 수행하는 동안 SQL 추적을 실행 한 다음 인덱스 / 구성을 변경하는 동안 해당 추적을 계속 재생하여 성능을 향상시키고 추적에서 논리적 읽기 및 CPU 메트릭과 같은 항목을 관찰하십시오.
브렌트 오자르

@AlexKuznetsov 저는 테스트를하는 사람이 아닙니다. 실제로 Eric은 질문을 한 사람입니다. 이런 종류의 작업을 수행 할 때 서버 수준뿐만 아니라 쿼리 수준에서 CPU 메트릭을 살펴 봅니다.
브렌트 오자르

우리는 제 3 자로드 생성기를 사용합니다 (그리고로드 테스트 개발을 전담하는 정규직 직원). 그래서 내 테스트는 트랜잭션, 순서, 사용자 수, 앱에서 수행 된 정확한 단계 등 모든 것에 정확합니다. 따라서 SQL 대시 보드 유형 메트릭을 전혀 볼 필요가 없습니다. 로드 테스트 소프트웨어는 앱 모듈의 응답 시간을 밀리 초 단위로 추적합니다. 따라서 DB 복원을 수행하는 것이 좋습니다. 테스트를하기 전에 "클린 슬레이트"상태를 달성하고 있는지 확인하기 위해 수행중인 다른 단계를 확인해야합니다.
Eric Higgins
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.