버스트 사용량에 대한 IO 요구 사항 추정

우리는 하루 종일 주기적으로 SQL 데이터베이스를 쿼리하는 응용 프로그램을 가지고 있습니다. 상대적으로 많은 양의 데이터에 대한 개별 요청과 함께 산재 해 있거나 활동이 적은 기간이 있습니다. 이러한 요청이 들어 오면 기본 목표는 데이터를 빠르게 전달하는 것이며, 보조 목표는 비용 효율적으로 수행하는 것입니다. 응용 프로그램의 특성상 데이터 / 인덱스가 이전 쿼리 (데이터의 다른 부분에서 작업하는 다른 사용자)의 RAM에 캐시되어있을 가능성은 거의 없습니다.

비교적 꾸준한 사용 경험이있는 시스템의 경우 디스크 큐 길이를 관찰하고 그 수를 상대적으로 작게 유지하는 경험이 있습니다. 이것은 특히 AWS에서 실행되며 100 IOPS 당 1의 디스크 큐 길이가 합리적이라는 경험을 보았습니다.

그러한 시스템의 IO 요구 사항을 어떻게 추정 할 수 있습니까? 개별적이고 복잡한 쿼리를 처리 할 때 디스크 큐 길이가 신뢰할 수있는 지표입니까? 고려해야 할 다른 메트릭이 있습니까?

SQL Server에서 IO에 대해 항상 고려한 기본 메트릭은 IOP 또는 디스크 큐 길이가 아니라 디스크 처리량 (초 / 읽기 및 초 / 쓰기)입니다. 전반적으로 데이터베이스는 디스크에서 얼마나 많은 작업을 처리 할 수 ​​있는지가 아니라 이러한 작업이 얼마나 빨리 완료되는지에 관한 것입니다. 일반적인 경험 법칙은 20ms / 조작 미만이어야합니다 (낮은 것이 항상 더 낫습니다). 자세한 내용은 이 기사를 참조하십시오 .

디스크 대기열 길이는 가짜 통계이며 더 이상 관련이 없습니다. 문제는 값이 단일 드라이브의 대기열을 측정하지만 이제는 RAID, SAN 및 기타 분산 스토리지의 시대에 살고 있기 때문에이 값을 의미있는 숫자로 올바르게 변환 할 수있는 방법이 없습니다. Quest / Dell 의이 포스터 는 성능 지표의 훌륭한 출발점 으로 중요한 이유 또는 이유에 대한 많은 정보와 설명을 제공합니다. 당신은 그들 모두를 사용할 필요는 없지만, 그들은 시작입니다.

IO를 테스트하려면 작업 부하가 최대인지 이해해야합니다. 얼마나 많은 트랜잭션과 캐시가 있습니까? 이것을 알고 측정하지 않으면 판단하기가 정말 어렵습니다. 워크로드를 작성하고 SQLIO 와 같은 도구를 사용 하여 스토리지를 테스트 할 수 있지만 적절한 테스트를 빌드하려면 워크로드 패턴이 필요합니다.

마지막으로 AWS에 대한 참고 사항 : Amazon은 AWS에서 IO 성능을 보장하지 않습니다. 이는 주로 스토리지가 방대한 공유 리소스이기 때문에 특정 스토리지 영역에서 사용자와 이웃의 패턴을 측정 할 수 없기 때문입니다 ( Noisy Neighbor 문제 참조 ).

가능한 한 많은 메모리를 할당하는 것이 좋습니다. SQL Server는 LRU-K를 기반으로하는 버퍼 풀의 공간과 압력이있는 경우에만 메모리에서 항목을 밀어냅니다. 따라서 버퍼 풀이 대부분의 데이터베이스를 메모리에 저장할 수있는 경우 일부 성능 저하를 완화 할 수 있습니다. 또한 캐시 개체를 "따뜻하게"유지할 수있는 전술을 고려하십시오. 마지막으로, SQL 2014 및 새로운 Hekaton 기능을 주시하십시오 .