SQL Server 쿼리에서 7MB / 초 이상의 디스크 I / O를 사용하지 않는 이유

IOmeter 테스트를 사용하여 200MB / s 이상의 성능을 보여주는 SSD가 있습니다. 그러나 로컬 컴퓨터에서 SQL 쿼리를 실행하면 Windows 리소스 모니터에 7MB / sec 이상의 디스크 IO가 표시되지 않습니다. 2 분이 넘는 쿼리를 실행하는 경우에도 마찬가지입니다. SSD에서 초당 7MB 만 사용한다는 병목 현상은 무엇입니까?

나는 뛰고있어:

Windows Server 2012 표준
SQL Server 2008 R2
인텔 i7 3820
램 32GB
샌 디스크 SSD

sql-server sql-server-2008-r2 hardware

— 딘 맥 그레 거
소스

아마도 데이터가 이미 RAM에 있고 디스크 액세스가 필요하지 않습니까?

— gbn

@DeanMacGregor-결과를 어떻게 소비하십니까? SSMS에있는 경우 결과를 삭제하는 옵션을 시도하면 어떻게됩니까? 그게 아무것도 바뀌나요? 또한 sys.dm_os_waiting_tasks쿼리가 실행되는 동안 다른 대기 유형이 있는지 확인 하려고 시도 할 수 있습니다 .

— Martin Smith

임의 액세스 읽기 (4KB 블록의 임의 읽기)의 경우 200MB / s입니까? 이것이 데이터베이스가 일반적으로하는 일이라고 생각합니다. 쿼리가 디스크 (임시 파일, 임시 결과 집합 또는 테이블)에 기록됩니까?

@DeanMacGregor-방정식에서 빼기 위해 스칼라 변수 (예제 쿼리)에 결과를 할당 할 수 있습니다. DECLARE @Name VARCHAR(10), @High int; SELECT @Name=name, @High = high FROM master..spt_values. 따라서 결과가 클라이언트로 다시 전송되지 않지만 계획과 IO는 여전히 동일합니다.

— Martin Smith

ASYNC_NETWORK_IO가 문제가 네트워크와 관련되어 있음을 의미한다고 해석한다고 가정하십니까? (일반적으로) 그렇지 않습니다. @MartinSmith가 SSMS 또는 사용중인 응용 프로그램이 SQL이 제공하는 것만 큼 빨리 결과를 소비하지 않는다고 제안했을 가능성이 큽니다. 제안 된 행 소비를 생략하는 방법 중 하나를 수행하면 최대 IO 처리량을 정확하게 볼 수 있습니다.

— Mark Storey-Smith

주석 체인 ASYNC_NETWORK_IO에서 문제가 네트워크와 관련이 있음을 의미하기 위해 기다리는 것으로 보입니다 . (일반적으로) 그렇지 않습니다.

@MartinSmith는 (두 번) 암시했을 때 SSMS 또는 SQL Server가 결과를 제공하는 것처럼 결과를 빨리 소비하지 않는 응용 프로그램입니다. 제안 된 방법 중 하나를 수행하여 측정에서 행 소비를 제거하면 최대 IO 처리량의 실제 그림을 얻을 수 있습니다.

아직 그렇지 않은 경우를 대비 DBCC DROPCLEANBUFFERS하여 버퍼 캐시가 아닌 디스크에서 실제로 데이터를 읽도록해야합니다. "테스트시에만, 실제 라이브 환경에서는이 작업을 수행하지 마십시오"등의 일반적인 경고가 적용됩니다.

다른 몇 가지 의견에 동의하십시오.

9 백만 행을 반환하는 쿼리를 실행하는 동안 CPU 사용량은 sqlserver에 기인 한 9 %로 약 13 %를 유지합니다 ... 모든 데이터가 RAM에 있으면 3 분보다 빠른 결과를 반환하지 않습니까?

여기서 정확히 무엇을 테스트하고 있습니까? 9 백만 행 쿼리가 다른 것이 아닌 경우 SELECT * FROM dbo.SomeTable에는 원시 IO 처리량 외에 1001 개의 요소가 있습니다.

귀하의 인텔 I7-3820은 4 코어 프로세서입니다. 테스트 쿼리가 병렬 계획을 생성하지 않으면 시스템에서 CPU 사용률이 20 % 이상 발생할 수 있다는 사실에 놀랐습니다.

9 백만 행을 반환하는 3 분은 매우 의심스럽고 테스트 결과를 완전히 파악하지 못하고 있습니다. 내 생각에 이것은 최적화되지 않은 (비 병렬) 쿼리 계획의 SELECT경우 IO 소비를 확인 하는 단일 테이블뿐만 아니라 수백만 행을 가져 오는 중첩 루프 연산자로 가득 차 있습니다.

나는 제안한다 :

SELECT *SQL Server를 통해 IO 만 테스트 합니다.
IO가 포화되지 않는 이유를 파고 싶다면 쿼리 실행 계획에 대한 새로운 질문입니다.

— 마크 층-스미스
소스

실제로는 dbo.sometable에서 *를 선택하기 만합니다. 더 이상 언급하지 않아서 죄송합니다. 내가 의미하는 것은 테이블에서 해당 쿼리를 실행할 수 있다는 것입니다. 내 질문의 기원은 단순한 "많은 데이터를 제공"쿼리 에서조차도 내 디스크 IO가 예상보다 훨씬 적다는 것을 알았습니다. 내 주요 관심사는 디스크 IO가 너무 낮 으면 낮은 디스크 IO의 근본 원인을 근절 한 경우 성능을 향상시킬 수 있다는 것입니다.

— Dean MacGregor