병렬 쿼리 실행 오류를 이해해야합니다.


18

오늘날 프로덕션 SQL Server의 성능이 저하되었습니다. 이 시간 동안 여러 "The query processor could not start the necessary thread resources for parallel query execution"오류 가 기록되었습니다 . 내가 읽은 것은 복잡한 쿼리를 실행할 때 사용할 CPU 수와 관련이 있음을 시사합니다. 그러나 정전 중에 확인했을 때 CPU Utilization was only at 7%. 내가 아직 보지 못한 다른 언급이 있습니까? 이것이 성능 저하의 원인일까요? 아니면 붉은 청어를 쫓고 있습니까?

이에 대한 내 sp_configure 값은 다음과 같습니다.

name                                minimum maximum config_value run_value
cost threshold for parallelism      0       32767   5            5

max degree of parallelismNUMA 구성과 함께 구성된 값은 얼마이며 현재 서버에 몇 개의 프로세서가 있습니까? sysinternals 에서 사용 coreinfo.exe하여 프로세서 수와 NUMA 구성을 찾을 수 있습니다.
— Kin Shah

최대 병렬 처리 수준이 0으로 설정 됨
— Lumpy

SQL Server가 스레드 리소스를 필요로하는 이유를 설명합니다.
— Kin Shah

@Kin 나는 12 개의 프로세서 (0-11) 프로세서를 가지고 두 개의 논리 프로세서를 NUMA 노드 맵에 넣습니다. 항목 Node 0, Node 1
— Lumpy

@ Kin SQL Server가 사용해야하는 스레드 수를 관리한다고 생각했습니다. 이로 인해 스레드 리소스에 대한 SQL Server가 고갈되는 이유는 무엇입니까?
— Lumpy

답변:


19

몇 달 전에 MAXDOP 설정이 기본값이고 런 어웨이 쿼리가 모든 작업자 스레드를 소진하는 유사한 상황에 직면했습니다.

Remus가 지적했듯이 이것을 작업자 스레드 기아 라고 합니다.

이 조건이 발생하면 서버에 메모리 덤프가 생성됩니다.

2008R2 + SP1 이상인 경우 sys.dm_server_memory_dumps덤프 파일 위치도 제공합니다.

이제 문제로 돌아갑니다.

NUMA 노드 당 1 개의 스케줄러 모니터 스레드가 있으며 2 개의 NUMA 노드가 있으므로 2 개의 스케줄러 모니터 스레드가 있으며,이 스케줄러 모니터 스레드는 해당 NUMA 노드에 대해 60 초마다 모든 스케줄러의 상태 점검을 담당하며 스케줄러가 멈췄는지 확인합니다. 아니.

스케줄러 작업자 큐에서 새 작업 요청을 가져올 때마다 작업 프로세스 카운터가 증가합니다. 따라서 스케줄러에 작업 요청이 대기 중이고 60 초 내에 작업 요청 중 하나를 처리하지 않은 경우 스케줄러가 정지 된 것으로 간주됩니다.

런 어웨이 쿼리 또는 광범위한 병렬 처리로 인해 단일 스레드 런 어웨이 쿼리 또는 과도한 장기 블로킹이 모든 스레드를 점유하고 작업자 프로세스가 종료되지 않는 한 작업을 수행 할 수 없으므로 작업자 스레드 상태가 소진되기 시작합니다.

가장 좋은 방법은 먼저 최대 병렬 처리 수준 설정을 조정하는 것입니다. 기본값은 0 SQL Server가 모든 작업자 스레드를 소진하여 병렬 처리를 위해 사용 가능한 모든 CPU를 사용할 수 있음 을 의미합니다.

작업자 스레드가 소진 될 수있는 여러 가지 이유가 있습니다.

  • SQL Server에 작업자 스레드가 부족한 광범위한 긴 차단 체인
  • 광범위한 병렬 처리로 작업자 스레드가 소진 됨
  • "잠금", 스핀 록, 래치 등 모든 유형의 대기 분리 된 스핀 락이 예입니다.

서버 인스턴스의 MAXDOP 값을 계산할 수있는 방법을 보여주는 여기의 답변을 참조하십시오 .

또한 데이터베이스 서버 인스턴스에 대한 대기 통계 정보 수집을 시작하는 것이 좋습니다 .


awway 쿼리 실행을 나타내는 것이 있습니까? 이 위험에 처한 쿼리를 식별하기 위해 사용할 수있는 것이 있습니까?
— Lumpy

상기 볼을 제안 대기 통계 발견하는 정보 는 아픈 . 또한 sys.dm_os_schedulers-> current_tasks_count, runnable_tasks_count, current_workers_count 및 active_workers_count sys.dm_os_wait_stats및sys.dm_os_waiting_tasks
— Kin Shah

10

몇 가지 이유가있을 수 있습니다. 아마도 당신은 일꾼이 없을 것입니다. 참조하십시오 max_worker_threads. 조건을 '작업자 계층화'라고합니다. CLR에서 많은 요청을 차단하거나 멍청한 일 (예 : HTTP 요청)을하는 등 여러 수단 중 하나 (둘 중 어느 것도 CPU 사용률이 높지 않음, btw)로 작업자를 도용 할 수 있습니다.

증상은 원인이 아니라 문제의 피해자입니다. 원인을 모르는 솔루션은 권장 할 수 없습니다. 성능 카운터, DMV를 수집하고 자세한 정보는 ERRORLOG를 확인해야합니다.


최대 작업자 스레드 최소 = 128, 최대 = 32767, 구성 = 0, 실행 = 0
— Lumpy

2
@Lumpy 구성 최대 값이지만 실제 최대 작업자 근처에는 없습니다. 머신이 계산해야하는 프로세서 수를 알아야합니다.
— 토마스 스트링거
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.