높은 CXPACKET 및 LATCH_EX 대기

작업중인 데이터 처리 시스템에 성능 문제가 있습니다. 1 시간의 peroid에서 대기 통계를 수집하여 많은 양의 CXPACKET 및 LATCH_EX 대기 이벤트를 보여줍니다.

이 시스템은 많은 수의 크 런칭 및 계산을 수행하고 데이터를 중앙 클러스터 서버에 공급하는 3 개의 처리 SQL Server로 구성됩니다. 처리 서버는 한 번에 각각 최대 6 개의 작업을 실행할 수 있습니다. 이 대기 통계는 bottlneck을 일으키는 중앙 클러스터에 대한 것입니다. 중앙 클러스터 서버에는 16 개의 코어와 64GB RAM이 있습니다. MAXDOP가 0으로 설정되었습니다.

CXPACKET이 여러 병렬 쿼리에서 실행되는 것 같지만 LATCH_EX 대기 이벤트가 무엇을 나타내는 지 잘 모르겠습니다. 내가 읽은 것에서 이것은 버퍼가 아닌 대기 일 수 있습니까?

누구나 이러한 종류의 대기 통계의 원인과이 성능 문제의 근본 원인을 조사하기 위해 어떤 조치를 취해야하는지 제안 할 수 있습니까?

상위 쿼리 결과는 총 대기 통계이고 하위 쿼리 결과는 1 시간 동안의 통계입니다.

CXPACKET은 LATCH_XX와 함께 제공 될 수 있습니다 (PAGEIOLATCH_XX 또는 SOS_SCHEDULER_YIELD도 가능). 이것이 사실이라면 (그리고 그것이 질문에 근거한다고 생각하면) 하드웨어에 맞게 MAXDOP 값을 낮추어야합니다.

이 외에도 다음은 SQL Server에서 무언가를 변경하기 전에 CXPACKET 대기 통계 값이 높은 원인을 진단하는 데 권장되는 몇 가지 단계입니다.

• 솔루션이 아니므로 MAXDOP를 1로 설정하지 마십시오.

• 쿼리 및 CXPACKET 히스토리를 조사하여 일반적으로 올바르게 작동하는 시스템에서 예외 일 수 있으므로 한 번 또는 두 번 발생한 일인지 이해하고 판별하십시오.

• 쿼리에 사용 된 테이블의 인덱스 및 통계를 확인하고 최신 상태인지 확인하십시오.

• 병렬 처리 비용 임계 값 (CTFP)을 확인하고 사용 된 값이 시스템에 적합한 지 확인하십시오.

• CXPACKET이 LCK_M_XX (보통 IO_COMPLETION 및 ASYNC_IO_COMPLETION과 함께)와 함께 제공되는지 확인하십시오. 이 경우 병렬 처리는 병목 현상이 아닙니다. 대기 통계에서 문제점 및 솔루션의 근본 원인을 찾기 위해 문제점 해결

CXPACKET 대기 유형에 대해 깊이 이해해야하는 경우 SQL Server의 CXPACKET 대기 유형 문제 해결 문서를 읽는 것이 좋습니다.

읽기 SQL 서버 진단 및 해결 래치 경합은 , 주제에 대한 가장 포괄적 인 종이입니다. 당신은 파고해야 sys.dm_os_latch_stats하고 래치 유형이 경합에 무엇을 참조하십시오.

SQL Server 성능 분석 방법이 어떤 식 으로든 도움이 되는지 읽어보십시오 .

위에 제공된 링크를 읽고 "최대 병렬 처리 수준"설정을 0에서 8과 같이 변경하는 것 외에도 병렬로 진행되는 쿼리와 비용을 좁히는 것이 좋습니다.

이 변경의 영향을 확인한 후 "병렬 처리 비용 임계 값"을 수정하여 병렬 처리 대상을 미세 조정할 수도 있습니다.

다음은 Brent Ozar의 멋진 비디오 입니다. CXPACKET 및 MAXDOP의 예술 마스터 링

귀하의 목표는 CXPACKET의 <= 50 % 퍼센트 대기 시간입니다. 행운을 빕니다!!