|
최대 개수를 정할 경우
Physical Core 개수로 정하는게 올바를 듯 하다.
이유는 나중에 설명해 보겠다.
사실 본인은 별로 중요하게 생각하지 않음.......^.^ 숙봉이도 어그리함, 그러나.....원리는 한번 고민해 보면 좋겠다.
Nexon 정상급 엔지니어 숙봉의 거친 지름을 받고서....쓰러짐...
서로 고민해 본다는 것이 즐거울 뿐이다. ;-)
스터디 중 송혁(MSSQL PFE)의 필드 경험 하나를 블로그에 담아둔다.
아래 현상이 일어나는 원인은 잘 모르겠다. 돈있고 힘있는 분은 escalation 해 차근 차근 설명 좀 해주세요~
SQL Server 의 Affinity Mask 를 설정해 SQL Instance 가 총 16개 core중 8개의 core 를 사용하게 설정 했을경우 (다른 경우도 마찬가지 이다) Serial 하게 열심히 돌아야 하는 쿼리를 동작 시키면 하나의 core 만 열심히 사용한다.
Affinity Mask 가 설정되지 않았을 경우나, Network 로 Bind 시킬 경우(Soft NUMA TCP/IP 로 여러개의 코어를 할당함) 선택된 코어 중 일량(load factor) 이 낮은 곳으로 옮겨 다시며 실행한다. 이는 같은 코어에서 실행하는 것이 해당 작업은 더 빠르게 끝날 수 있지만 전체 시스템 성능(효율)을 좋게 하기위해 한가한 core Pool 내에서 옮겨 다니며 실행 하도록 한 원래 아키텍처에 위배되는 행위가 아닐까 생각된다. (이런경우 난 이해가지 않으면 버그 스럽다 혹은 개발자의 한계가 이까지 인갑다 라고 생각 한다. -_-+)
다른 OS 스케줄러도 거의 다 비슷하게 동작한다. 로드를 보고 이쪽 저쪽 옮겨 다니며 실행. 그런데, SQL Server 의 경우 Affinity Mask 를 설정 했을때 Serial 한 쿼리를 동작 시키면 하나의 코어먄 100% 다 쓴다.
참고로 Affinity Mask 는 향후 없어진다고 한다.
위 현상은 SQL Server 2005 이상에서 비슷 할 것으로 보이고, 우린 SQL Server 2008R2 에서 테스트 했다.
affinity mask 설정 후 다음을 쿼리 해보면, manual 로 바뀌어 있는것을 볼 수 있다.
select affinity_type_desc from sys.dm_os_sys_info
몇 몇 경우에 min max 함수를 사용 할 때와 order by top 1 을 사용할 때의 성능이 틀릴 때가 있다.
이 경우 workaround 로 top 1 을 사용하면 된다.
Fix 된 버그
http://support.microsoft.com/kb/973255/en-us
Hotfix 적용 후 4199 TF 를 enable 해줘야 한다.
파티션 테이블에서의 문제
이거 만든사람 귀차니스트가 아닐까...... row_numner()
