성능 문제를 검토하는 동안 CXPACKETS에 유입되는 것을 보았습니다. 수도 병렬 아마도 MAXDOP에 대한 비용 임계 값을 볼 필요가 있습니다.
MAXDOP를 대폭 변경하기 전에 CXPACKET 에 대한 응답으로 @mrdenny 의 조언을 포함하여 많은 다른 사람들의 조언을 따랐습니다 .SQL Server 2008의 성능 조정 대기 과 @에서 아론 베르트랑의 대답 비용 임계 값 설정 - CXPACKET 대기 다루기를 병렬 처리 . 야간에 통계를 완전히 업데이트하기 위해 유지 관리에 추가했습니다. 이것은 현명한 움직임처럼 느껴집니다.
그러나 비용 임계 값을 수정하는 것은 여전히 나쁜 일입니다.
병렬 처리에 대한 비용 임계 값은 어느 시점에서 변경되어야합니까? 쿼리 및 워크로드 비용을 조사한 후이 비용을 어디에서 변경했는지에 대한 예가 있습니까?
이것이 이전 질문에서 답변 된 것이라면 사과드립니다.
감사!
답변:
MAXDOP = 1을 사용하면 도움이 될 수 있지만 큰 총입니다. 실제 문제는 인덱스의 유용성 일 수 있습니다. 아마도 새 인덱스 나 다른 인덱스가 문제를 해결했을 것입니다.
Denny와 Aaron Bertrand의 의견에 따라 CXPACKET 대기의 원인이 될 수있는 다른 대기 항목을 발견 했습니까?
Jonathan Kehayias는 병렬 처리 경험을 평가하고보다 신중한 결정을 내리는 데 도움이되는 쿼리를 제안했습니다. 그러나 Jonathan과 Paul White의 대화도 읽어야합니다.
https://www.sqlskills.com/blogs/jonathan/tuning-cost-threshold-for-parallelism-from-the-plan-cache/
사용 가능한 모든 스레드를 소비하는 런 어웨이 쿼리가 스레드 기아로 이어질 수 있으므로 기본 설정 0 (사용 가능한 모든 스레드 사용)이 위험 할 수 있으므로 MAXDOP 설정을 먼저 살펴 보는 것이 좋습니다.
서버 인스턴스의 MAXDOP 설정을 계산하는 방법은 여기 내 답변을 참조하십시오 .
병렬 처리의 비용 임계 값은 옵티마이 저가 병렬 처리를 고려하기 전에 최소 쿼리 비용이 얼마인지를 나타냅니다.
CXPACKET 대기 시간은 오래된 통계 또는 인덱스 누락으로 인해 쿼리와 관련하여 잘못되었거나 계획이 잘못되었거나 다른 증상으로 인한 증상 일뿐입니다.
당신은 사용할 수 있습니다 sys.dm_exec_cached_plans과 sys.dm_exec_query_plan에 설명 된대로 DMV는 계획 캐시에서 내 정보로의 계획 캐시에서 '병렬 처리에 대한 비용 임계 값'튜닝 조나단에 의해 병렬 처리에 대한 비용 임계 값 .
cost threshold for parallelism리소스 튜닝 쿼리를 모두 사용하지 않고 인덱스 및 통계를 유지 관리하고 쿼리에 도움이 될 수있는 누락 된 인덱스가 없는지 확인하지 않는 한 기본값 을 유지하는 것이 좋습니다 .
참고 : Maxdop 설정은 OPTION (MAXDOP n)서버 수준 설정을 무시하는 쿼리 수준에서 적용 할 수도 있습니다 .