tempdb에 대한 해시 / 정렬 유출 빈도는 무엇입니까?

우리의 엔터프라이즈 응용 프로그램은 데이터 저장을 위해 SQL Server를 사용하며 주로 OLTP 시스템입니다. 그러나 응용 프로그램의 중요한 구성 요소는 상당한 OLAP 작업 부하를 생성합니다.

tempdb에 대한 쓰기 대기 시간은 약 100ms입니다. 이 추세는 시간이 지남에 따라 유지되며 ALLOW_SNAPSHOT_ISOLATION꺼져 있습니다 . 우리는 문제와 관련하여 문제를 해결하고 있으며 지금까지 찾은 유일한 흥미로운 점은 tempdb에 많은 수의 해시 및 정렬 유출이 있다는 것입니다. 우리는 이것이 OLAP 워크로드에서 발생한다고 가정합니다.

질문

유출 빈도는 어느 정도입니까? 어떤? 유출 / 초는 몇 번입니까? 예비 데이터에 따르면 초당 약 2 회의 해시 유출과 분당 25 회의 정렬 유출이 있습니다.

이러한 유출 빈도가 높은 tempdb 쓰기 지연 시간의 주요 원인이 될 수 있습니까?

기타 정보

코어 수당 권장되는 tempdb에 여러 파일을 사용하고 있습니다. tempdb 파일은 RAID 1 + 0 SAN (고성능 SSD 포함)에 있지만 주 DB 데이터 및 로그 파일과 동일한 장치입니다. tempdb 파일의 크기는 매우 드물게 커질 수 있습니다. 우리는 추적 플래그 1117 또는 1118을 사용하지 않습니다. 또 다른 변수는이 설정이 모두 중간에서 높은로드를 경험하는 여러 데이터베이스에 대해 공유된다는 것입니다.

100ms 쓰기 대기 시간은 MSDN, SQL Skills 및 기타 사이트에서 찾은 tempdb 쓰기 대기 시간의 허용 범위보다 훨씬 큽니다. 그러나 다른 데이터베이스의 쓰기 대기 시간은 좋습니다 (10ms 미만). 다른 통계에 따르면, 특히 내부 객체에 tempdb를 많이 사용하는 것으로 보입니다. 우리는 왜 어플리케이션이 내부 객체를 그렇게 많이 사용하는지 알아 내려고 노력하고 있습니다.

우리는 플랫폼에서 다양한 방식으로 나타나는 실제 성능 문제가 있습니다. 우리는 성능 카운터를 모니터링하고, DM 뷰를보고, 시스템의 리소스 사용 특성을 찾기 위해 앱 동작을 분석했습니다. 유출이 메모리가 아닌 디스크에서 수행되기 때문에 유출에 막대한 부정적인 영향이 있음을 읽었으므로 지금 유출에 중점을 둡니다. 우리는 유출이 매우 많은 것으로 보이지만 사람들이 "높은"것으로 간주하는 것에 대한 정보를 얻고 싶었습니다.

이러한 유출 빈도가 높은 tempdb 쓰기 지연 시간의 주요 원인이 될 수 있습니까?

일반적으로 유출의 평균 크기와 빈도 자체보다 더 중요한 유출의 정도 (재귀 해시 유출, 다중 패스 정렬) 는 가능 하지만 가능합니다 .

SQL Server는 tempdb 압력에 대한 다양한 기여 요인의 문제를 해결하는 데 도움이되는 광범위한 메트릭 및 DMV 정보를 제공합니다.이 중 다수는 Microsoft 기술 문서 "SQL Server 2005의 tempdb 작업" (2005 년 이후 버전에 적용됨)에서 설명합니다. ).

해당 문서에 포함 된 지침 및 진단 쿼리를 사용하여 tempdb 압력의 주요 원인을 식별 할 수 있어야합니다. 단순히 버전 저장소 활동 ALLOW_SNAPSHOT_ISOLATION이 활성화되어 있지 않기 때문에 무시하지 마십시오 . 많은 기능이 스냅 샷 격리 외에 버전 저장소 (예 : 트리거, MARS, RCSI)를 사용합니다.

정렬 및 해시 유출이 높은 수준에서 중요한 것으로 판명되면 이에 대한 특정 모니터링을 설정해야 할 것입니다. SQL Server 버전에 따라 약간 간단하지는 않습니다. 정렬 및 해시 유출을 발생시킨 특정 쿼리와 연결하려면 이벤트 알림 또는 확장 이벤트가 필요합니다. SolidQ 기사 " 정렬 경고 식별 및 해결 "에는 일반적인 원인 해결에 대한 세부 정보와 일반적인 조언이 포함되어 있습니다.

또한 스토리지 팀과 협력하여 워크로드에 따른 대기 시간의 양, 다른 공유 용도의 양 및 재구성을위한 옵션을 결정해야합니다. SQL Server의 메트릭을 분석하면 SAN 직원이 ​​제공 할 수있는 메트릭과 마찬가지로이 토론에 도움이됩니다.