SQL Server-누구나 SUMA, 추적 플래그 8048 또는 추적 플래그 8015를 사용합니까?

최근 SQL Server 2008 R2 시스템에서 심각한 스핀 록 경합 문제를 해결하기 위해 SQL Server 시작 추적 플래그 8048이 포함되었습니다.

성능 플래그가 추적 플래그 8048 (NUMA 당 노드에서 코어로 쿼리 메모리 부여 전략 승격), 추적 플래그 8015 (SQL Server는 실제 NUMA를 무시 함) 또는 SUMA에 의해 전달 된 사용 사례를 발견 한 다른 사람들의 의견을 들었습니다. 일부 NUMA 시스템의 BIOS 옵션으로 충분히 균일 한 메모리 액세스를 인터리브했습니다.

추적 플래그 8048 http://blogs.msdn.com/b/psssql/archive/2011/09/01/sql-server-2008-2008-r2-on-newer-machines-with-more-than-8-cpus -노드 당 노드 수-추적-플래그-플래그 -8048.aspx

추적 플래그 8015 http://blogs.msdn.com/b/psssql/archive/2010/04/02/how-it-works-soft-numa-io-completion-thread-lazy-writer-workers-and-memory -nodes.aspx

시스템 워크로드, 문제가 발생한 시스템에서 메트릭을 수집하고 개입 후 시스템에서 메트릭을 수집합니다.

추적 플래그 8048은 '수정'이지만 가장 좋은 수정입니까? 추적 플래그 8015로 인해 물리적 NUMA를 무시하는 SQL Server가 동일한 작업을 수행 했습니까? 메모리를 인터리브하도록 BIOS를 설정하고 서버에 NUMA 동작 대신 SMP- 모방 SUMA 동작을 남겨 두는 것은 어떻습니까?

평화! tw : @sql_handle

시스템 정보 :-4 개의 육각 코어 Xeon E7540 @ 2.00GHz, 하이퍼 스레드-128GB RAM-WS2008R2-MSSQL 2008 R2 SP2-maxdop 6

워크로드 정보 :-2 개의 보고서 응용 프로그램 서버에서 구동되는 1000 개의 Batch 예약 / 대기 보고서. -3 가지 종류의 배치 : 매일, 매주, 매월-SQL Server에 대한 모든 보고서 응용 프로그램 서버 연결은 단일 서비스 계정으로 이루어집니다.-최대 보고서 동시성 = 90

문제가 발생한 시스템의 주요 결과 :-Perfmon에서 15 초 간격-시스템의 95 % -100 % CPU 사용 중-SQL Server 버퍼 페이지 조회 <10000 / 초 / 초

• 대기 및 스핀 록 DMV에서 5 분 간격
• • 높은 CMEMTHREAD 웨이터 및 대기 시간
• • 높은 SOS_SUSPEND_QUEUE 스핀 및 백 오프

추적 플래그 8048에 대한 Bob Dorr의 CSS 엔지니어 블로그 게시물에 따르면 NUMA 노드 당 8 개 이상의 코어가있는 시스템은 쿼리 메모리 부여의 병목 현상으로 인해 유사한 증상이 발생할 수 있습니다. 추적 플래그 8048은 전략을 NUMA 노드 대신 코어별로 변경합니다.

개입

-T8048을 사용하여 MSSQL을 다시 시작했습니다. 그 차이는 즉시 분명해졌습니다. 버퍼 페이지 조회 속도는 백만 이상 증가했으며 초당 8 백만으로 급증했습니다. 이전에는 24 시간 내에 완료 할 수 없었던 문제가 발생한 배치 워크로드가 4 시간 이내에 완료되었습니다. 조사 또는 개입의 초점이 아닌 다른 배치 워크로드는 추적 플래그 8048의 수정 값을 검증하는 것의 일부로 제출되었습니다 (원치 않는 부작용을 최소화 함). 이 보고서 배치는 이전에 2 시간 내에 완료되었습니다. 추적 플래그가 8048 인 상태에서 보고서 배치가 약 20 분 안에 완료되었습니다.

야간 ETL에도 이점이있었습니다. ETL 시간이 약 60 분에서 40 분으로 감소했습니다.

여러 곳에서 정보를 모아서 높은 수준의 보고서 대기열, 하드웨어 스레드 수보다 많은 동시 보고서 수 및 작업자 스레드 압력이 발생할 때까지 하나의 NUMA 노드에 압력을 가하기 위해 모든 보고서에 대한 단일 사용자 계정이 결합되었다고 추측합니다. 동일한 사용자 계정에 대한 다음 수신 연결 요청에 대해 바람직하지 않습니다.이 시점에서 다음 NUMA 노드는 거의 즉시 많은 수의 연결을 얻습니다. 각 NUMA 노드는 쿼리 메모리 부여 병목 현상을 유발할 가능성이 높습니다.

쿼리 메모리 부여를 위해 더 많은 레인을 열면 병목 현상이 제거되었습니다. 그러나 비용이 확실하지 않습니다. Bob Dorr의 CSS 게시물을 통해 추적 플래그 8048이있는 추가 메모리 오버 헤드가 있음을 알 수 있습니다. 단일 페이지 할당 자 영역 내의 오버 헤드는 MSSQL 2008 R2 max 서버 메모리에 의해 관리됩니까? 그렇다면 시스템이 버퍼 풀 캐시에 데이터베이스 페이지 수를 줄이게 될 것입니다. 그렇지 않은 경우 최대 서버 메모리를 낮추어 수용해야합니까?

이것은 멋진 게시물입니다.

마지막 질문에 대답하기 위해 귀하의 답변이 "예"라고 추측합니다.

즉, 아마도 추적 플래그에 의지하기 전에 부드러운 누마를 추구했을 것입니다. 나는 당신이 numa node 할당에 대해 옳았다 고 생각하며 그것은 문제의 근원 일 수 있습니다. 소프트 numa를 통해 numa 노드 수 (4?)에 따라 요청을 스케일 아웃 할 수 있습니다 (올바른 숫자 인 경우 4까지). 그런 다음 ip 주소를 통해 각 호스트를 특정 numa 노드에 할당하십시오. 이를 위해 하이퍼 스레딩을 비활성화합니다. 결합하면 문제가 줄어들 것 같지만 더 적은 스케줄러를 사용하여 비용이 줄어 듭니다.

별도의 생각으로, 강제 매개 변수화를 살펴볼 것입니다. 부하가 CPU를 너무 많이 몰고 있다는 사실은 매우 흥미 롭습니다.

마지막으로, 다중 노드 노드 시스템에서는 일반적으로 N 초마다 테이블에 다음 쿼리를 출력합니다. 워크로드 변경 또는 추적 플래그가 구현 될 때 몇 가지 흥미로운 분석을 수행합니다.

SELECT getdate() as poll_time, node_id, node_state_desc, memory_node_id, online_scheduler_count, active_worker_count, avg_load_balance, idle_scheduler_count
FROM sys.dm_os_nodes WITH (NOLOCK) 
WHERE node_state_desc <> N'ONLINE DAC'

과

SELECT top 10 getdate() as sample_poll, wait_type, count (*)
FROM sys.dm_os_waiting_tasks
WHERE [wait_type] NOT IN
('CLR_SEMAPHORE','LAZYWRITER_SLEEP','RESOURCE_QUEUE','SLEEP_TASK','SLEEP_SYSTEMTASK',
'SQLTRACE_BUFFER_FLUSH','WAITFOR', 'BROKER_TASK_STOP',
'BROKER_RECEIVE_WAITFOR', 'OLEDB','CLR_MANUAL_EVENT', 'CLR_AUTO_EVENT' ) 
GROUP BY wait_type
ORDER BY COUNT (*) DESC