NUMA 노드와 추척플래그 8048

NUMA 노드와 추척플래그 8048

 

• Version : SQL Server 2008, 2008R2, 2012

 

SQL Server 2008 이상의 NUMA NODE 환경에서 노드당 CPU가 8개 이상 사용되는 서버에서 추적 플래그 8048이 필요한 경우를 살펴보자

 

이번 포스트는 CSS SQL Server Engineer 팀블로그에 게제된 내용으로 필자가 이해한 내용을 바탕으로 정리 하였으며 번역의 오류나 기술적 오류가 있음을 인지 한다.

 

SQL Server 개발자는 메모리 사용에 따라 서로 다른 수준의 파티션 메모리를 할당하도록 선택 할 수 있다. 개발자는 글로벌, CPU, NODE, 작업 파티션 스키마를 선택 할 수 있다.

 

SQL Server에서는 CMemPartitioned 할당을 사용한다. 이 파티션의 CPU 또는 NUMA 노드 메모리는 동시성과 성능이 향상 된다.

 

CMemPartitioned는 일반적인 힙(heap)과 개념이 비슷하다.(하지만 HeapCreate와는 다르다). 힙을 만들고 동기화 할 때 기본 크기 및 기타 속성을 평가 한다. SQL Server 개발자는 메모리 개체를 만들 때 스레드의 안전한 액세스, 파티션 구성 표 및 기타 옵션 같은 것들을 나타낸다.

 

 

개발자가 객체를 만들면 새로운 할당 동작이 발생 한다. 왼쪽 요청은 노드 기반의 메모리 개체에 대한 작업이다. 이 개체의 동기화는 (일반적으로 CMEMTHREAD 또는 SOS_SUSPEND_QUEUE 타입) 할당된 NUMA 노드 작업의 노드 레벨에서 할당된 로컬 메모리를 사용한다.

오른쪽은 CPU 기반의 메모리 개체에 할당 한다. 이 개체의 동기화는 할당된 CPU 작업의 CPU레벨에서 할당된 로컬 메모리를 사용한다.

 

대부분의 CPU 기반의 디자인의 경우 SQL OS 논리적 스케줄링을 처리하는 방식으로 동기화 충돌을 최대한 줄일 수 있다. 선점(preemptive)과 백그라운드 작업은 충돌이 가능하지만 가능한 CPU 레벨에서 빈도를 최대한 낮춘다. 그러나 CPU 기반의 파티션은 개별 CPU 액세스 경로와 관련 메모리 목록을 유지하기 위해 더 많은 오버헤드를 발생 시킨다.

 

노드 기반 디자인 경우 노드에 대한 오버헤드를 줄일 수 있지만 충돌 가능성이 약간 증가 한다. 매우 구체적인 시나리오에서는 최고의 성능 결과에 영향을 준다.

 

다음과 같이 멀티 코어 CPU 환경에서 단일 NUMA 노드 내에 8개 이상의 CPU를 사용할 때 Microsoft는 노드 당 8개의 CPU 접근을 초과할 경우 할 경우 노드 기반의 파티셔닝은 특정 쿼리 패턴에서 확장하지 않음을 관찰 했다. 그러나 추적플래그 8408을 사용하면 모든 NODE 기반의 파티션을 CPU기반 파티션으로 업그레이드 된다. 이 방법은 메모리 오버헤드를 증가시키지만 시스템에서 성능 향상을 제공한다.

 

추적플래그 8408의 필요성 판단은 어떻게 할까?

마이크로소프트의 CSS에서는 DMV의 dm_os_wait_stats 및 dm_os_spin_stats(CMEMTHREAD 및 SOS_SUSPEND_QUEUE)으로 매우 큰 수의 스핀 점프 핫 스팟을 확인 한다.

 

[참고자료]

http://blogs.msdn.com/b/psssql/archive/2011/09/01/sql-server-2008-2008-r2-on-newer-machines-with-more-than-8-cpus-presented-per-numa-node-may-need-trace-flag-8048.aspx

 

 

2013-07-23 / 강성욱 / http://sqlmvp.kr