보미네

1분 단위 append only store 의 저장소가 생기고 Truncate 하는 식으로 동작해

생기는 현상을 이해를 할 수 있어 좋았다. 만든사람 참 고민을 많이 한듯하다.

스터디는 매일 뭔가 새로운 것을 배울 수 있어 너무 좋다.

SQLTAG 의 똘똘이 현주의 강의를 듣고....

최대 개수를 정할 경우

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