왜 tempdb에 대해 io_stall_writes_ms가 훨씬 더 높습니까?

동일한 디스크 드라이브에 사용자 및 시스템 데이터 파일이 있습니다. (io_stall_write_ms / (1.0 + num_of_writes))는 사용자 파일의 경우 2 미만이지만 tempdb 파일은 일반적으로 400 이상입니다. 몇 대의 서버에서 tempdb에 쓰는 데 더 오래 걸리는 이유가 있는지 궁금합니다. 일반 데이터베이스 데이터 파일보다.

SELECT DISTINCT UPPER(LEFT(mf.physical_name, 1)) AS Directory,
( io_stall_write_ms / ( 1.0 + num_of_writes ) ) as result, 
io_stall_write_ms, num_of_writes, 
fs.database_id, 
fs.[file_id]
FROM sys.dm_io_virtual_file_stats(NULL, NULL) AS fs
INNER JOIN sys.master_files AS mf ON fs.database_id = mf.database_id
AND fs.[file_id] = mf.[file_id]

감사합니다,

짧은 답변 : 더 높은 IO 스톨을 보는 것은 그 자체로는 문제가 될 수도 있고 아닐 수도 있습니다. 문제가있는 경우 더 자세한 정보를 확인해야합니다. 조금 높은 것 같지만, 고통 스럽습니까? 그렇다면 IO 시스템이로드를 올바르게 처리하지 못하거나 (하나의 드라이브에 모든 것이 있거나 다른 이유가 있기 때문에 할 수 없기 때문에) TempDB에서 너무 많은 일을하고 있기 때문일 수 있습니다 (첫 번째 문제 변경- IO 성능-더 쉽고 효율적인 수정일 수 있지만 먼저 문제가 있는지 확인하십시오.)

더 긴 토론 / 답변 :

여기에 두 가지 질문이 있습니다-

1.) IO 스톨이 많으면 어떻게해야합니까?

우선, "높은"은 보는 사람의 눈에 있습니다. 10 개의 DBA에게 IO 스톨에 대해 "너무 높은"것이 무엇인지 물어 보면 아마도 2-3 개의 다른 답변, 5-6 개의 "그것은 달려있다"라는 대답과 한 개의 빈 응시를 얻게 될 것입니다. 내 가정은 평균 400ms가 잠재적으로 너무 높을 때, 특히 다른 DB가 평균 스톨 시간 동안 2ms 이하인 경우입니다.

어느 데이터베이스가 높은 실속을 보이는지에 관계없이 같은 방식으로 접근해야합니다. IO 스톨은 다음과 같습니다 : IO 요청이 예상보다 오래 걸립니다. 스톨. 이런 일이 발생합니다. 자원은 공유되고 유한 자원 (실제로 모든 시스템)이있는 시스템에서 항상 발생합니다. 스톨이 성능 문제가되거나 문제가 발생할 때 문제가됩니다. 따라서 귀하가 여기를 모니터링의 사전 예방 적 부분으로보고 있거나 문제를 해결하는 성능 문제가 발생한 것으로 판단합니다. 우리는 또한 IO 스톨에서 길을 잃고 싶지 않습니다. 우리는 큰 그림이 아니라 퍼즐 조각을보고 있습니다. SQL을 마지막으로 다시 시작한 이후 항상 대기 통계 또는 파일 통계를 살펴 보는 것이 번거로울 수 있으며 일부 유지 관리 기간이나 무거운로드 창으로 인해 카운터가 왜곡 될 수 있습니다. 따라서 전체 그림을 확인하십시오.

그러나 디스크 성능 문제가 있거나 이와 같은 쿼리에서 문제가 발생하면 일반적으로 다음과 같은 프로세스를 따릅니다.

1. 서버에서 대기 통계를보십시오. @swasheck 은 아래 답변에서 주석으로 훌륭한 링크 를 공유했습니다 . 이를 통해 SQL Server의 대기 통계를보고 분석하는 Paul Randal의 게시물로 이동합니다. 저기로가. 당신은 어떤 종류의 대기를보고 있습니까? 당신은 IO 성능 (관련 대기 보는가 PAGEIOLATCH_*, IO_COMPLETION, WRITELOG, 등?)를. 이 작업을 수행하면 IO 중단과 마찬가지로 일부 IO 관련 성능 문제가 있음을 나타냅니다. 그러나 여기에 또 다른 형태의 합의가 있습니다.
2. IO 성능을보십시오. 특히 perfmon 내부 Physical Disk:Avg Disk Sec/Read와 Avg Sec Disk Sec/Write카운터를 살펴보십시오 . 대기 시간을 측정합니다. 성능 카운터 파일에 저장된 일정 기간 동안이 카운터를보십시오. 평균에 대해 무엇을 보셨습니까? 0.020 초 (20ms) 이상의 숫자가 표시되면 문제가 될 수 있습니다. 평균 40-50ms 이상의 숫자가 표시되면 문제가 더 확실하게 나타납니다. 스파이크도 보시겠습니까? 그들은 얼마나 높이 가고 얼마나 오래 지속됩니까? 수백 ms에 스파이크가 발생하고 수십 초 또는 몇 초 이상 지속되거나 자주 발생하는 경우 워크로드의 IO 성능에 문제가있을 가능성이 높습니다.
3. IO 설정을보십시오. 무엇입니까? 로컬 디스크? SAN? 스토리지 배열? 이 중 어떤 종류의 IOP와 IOP를보아야합니까? 당신이하려는 일에 충분합니까? 워크로드에 맞게 IO를 축소했을 수 있습니다. 물리적 스핀들, RAID 설정 등 만 보지 마십시오. 디스크 경로를 확인하십시오. 다른 많은 트래픽과 공유하는 단일 1GB 링크를 통해 모든 것을 추진하고 있습니까? 스토리지 관점에서 디스크 성능 메트릭을 볼 수 있습니다.

( 참고 : 이 대기 통계 분석 및 perfmon 분석의 경우 다양한 기간과 사용 유형을 확인하십시오. 야간에 사용하는 시간과 다른 사용 통계가 있습니까? 일괄 처리 창? 많은 색인을 다시 작성하는 유지 관리 창? 각 기간 동안 이러한 도구를보고 각각에 대해 무엇을보고 있는지 이해하십시오.)

또 다른 IO 성능 고려 사항-

• 시스템 DB와 사용자 DB가 공유되어 있다고 말했습니다. 이거 생산인가요? 그렇다면 항상 최상의 시나리오는 아닙니다. 동일한 드라이브에서 로그 파일과 데이터 파일도 공유하고 있습니까? 그것은 최고의 시나리오도 아닙니다. 이 스토리지를 공유하는 다른 것은 무엇입니까? 스핀들과 공격대 그룹 및 디스크에 대해 걱정하고 누가 가장 성능이 우수한 디스크를 얻는 지 결정해야하는 세상에서 나는 (일반적으로 경험할 수 있습니다.) DB 세계에서는 그리 좋지 않습니다. 그러나 이것은 사실을 유지하는 경향이 있습니다) 내 가장 빠르고 가장 Tempdb (아래에 더 자세히 설명되어 있음), 로그 파일, 데이터 파일을 사용합니다. NetApp, Dell Equal Logic 또는 EMC VNX 등과 같은 장치에 큰 디스크 더미가있는 세상에서는

2.) TempDB가 더 높은 이유는 무엇입니까?

따라서 TempDB는 데이터베이스이며 방금 설명한 다른 데이터베이스와 마찬가지로 IO가 중단 될 수 있습니다. 그러나 TempDB가 더 높은 읽기를 가질 수있는 이유는 무엇입니까? (완전한 것은 아니며, 편집, 기타 답변 또는 의견의 추가 또는 생각을 환영합니다)-

1. 코드 때문에-코드에서 TempDB를 많이 사용하고 있습니까? 많은 임시 테이블과 테이블 변수가 생성되고 파괴됩니까? TempDB에서 이와 같이 많은 일을합니까? 반드시 나쁘거나 좋지는 않지만 의도 한 TempDB 사용 패턴을보고 이해할 수 있습니다.
2. TempDB는 공유 작업량입니다. TempDB는 사용자 정의 임시 개체와 전체 SQL 인스턴스에서 사용되는 다양한 작업 테이블 및 작업을위한 임시 공간으로 사용되는 데이터베이스입니다. 사용자 DB는 몇 개입니까? 일반적으로 어떤 종류의 작업이 보입니까? TempDB는 모든 것을 공유 할 수있는 하나의 리소스입니다.
3. 비효율적 인 쿼리 및 메모리 부족-인덱스를 충분히 사용하지 않거나 대규모 스캔 및 정렬 작업을 수행하는 쿼리가있을 수 있습니다. 대규모 해시 작업과 서버의 메모리로는 충분하지 않습니다. 이러한 작업은 뒤에서 작업 테이블로 TempDB에 "유출"됩니다. 쿼리 계획과 인덱싱 또는 쿼리 튜닝을 살펴보면이를 피할 수 있습니다. 때로는 발생합니다 (웨어 하우스 워크로드에서 더 그렇습니다). 메모리가 충분하면 도움이 될 수 있지만 이러한 쿼리는 때때로 유출 될 수 있습니다. 이것도보세요.
4. 시스템에서 상당한 수의 업데이트로 커밋 된 스냅 샷 격리 수준을 사용하고 있습니까? 또한 TempDB 활동이 증가 할 수 있습니다.

요점은-TempDB는 많은 방법으로 사용되며, 가장 바쁜 데이터베이스는 아니지만 가장 바쁜 데이터베이스 중 하나로 보는 것이 전혀 놀랍지 않습니다. 또한 클라이언트 사이트에서 모든 데이터베이스의 수가 가장 많고 평균적인 스톨이있는 것으로 볼 때 놀라지 않습니다. 때로는 작업 부하의 특성입니다. 여기에 언급 된 사항 중 일부를 살펴보면이 숫자가 문제를 나타내는 지 여부와 문제를 해결하는 데 더 깊이 들어가는 방법을 결정하는 데 도움이 될 수 있습니다.

TempDB는 인스턴스의 모든 데이터베이스간에 공유됩니다. 따라서 특정 페이지 SGAM , GAM 및 PFS에 대해 TempDB 내에 경합이있을 수 있습니다 . 간단히 말해,이 페이지는 지금까지 TempDB에서 사용 된 내용과 새로운 용도로 사용할 수있는 공간을 추적합니다.

일반적으로 이는 여러 데이터 파일을 TempDB에 추가하여 처리됩니다. 올바른 숫자에 대해서는 몇 가지 다른 철학이 있지만 모두 하나 이상이 있어야한다는 데 동의합니다.

실행할 몇 가지 쿼리는 다음과 같습니다.

이것은 TempDB가 가지고있는 파일의 수와 위치를 보여줍니다.

-- tempdb layout
use tempdb
go
exec sp_helpfile
go

이것은 당신이 얼마나 많은 CPU와 코어를 가지고 있는지 보여줄 것입니다.

-- cores and hyperthreading
select cpu_count, hyperthread_ratio 
from sys.dm_os_sys_info
go

이것은 NUMA 노드 당 NUMA 노드와 코어 수를 보여줍니다.

-- numa nodes and schedulers
select node_id, online_scheduler_count
from sys.dm_os_nodes
order by node_id
go

TempDB에서 어떤 페이지가 대기 중인지 보여줍니다.

-- see if anything is waiting on tempdb
select * 
from sys.dm_os_waiting_tasks
where resource_description like '2:%'
go

다음은 페이지 경합 문제에 대해 좀 더 자세히 다루는 기사입니다.

이제 철학 부분은 ... :-)

필자가 SMP 시스템 을 사용하는 경우 전체 코어의 절반 정도의 파일 만 원합니다 .

NUMA 시스템 을 사용하는 경우 NUMA 노드 당 코어 수 만큼의 파일 만 원합니다 .

그러나 TempDB에 대해 4 개 이상의 파일을 보유한 경우에는 거의 개선되지 않았습니다. 그래서 나는 보통 4 개로 시작하여 링크 된 기사에 설명 된대로 경합을 모니터링합니다.

문제가 계속되면 두 개를 더 추가합니다. 다시 확인하고 추가 한 후 경합이 사라질 때까지 반복하십시오.