스레드 풀 속성

Analysis Services는 여러 작업에 다중 스레드를 사용하여 여러 작업을 병렬로 실행함으로써 전반적인 서버 성능을 향상시킵니다. 스레드를 보다 효율적으로 관리하기 위해 Analysis Services는 스레드 풀을 사용해서 스레드를 미리 할당하고 다음 작업에 스레드를 쉽게 사용할 수 있도록 지원합니다.

각 Analysis Services 인스턴스는 고유한 스레드 풀 집합을 유지 관리합니다. 테이블 형식과 다차원 인스턴스에서 스레드 풀이 사용되는 방법에는 중요한 차이점이 있습니다. 가장 중요한 차이점은 다차원 솔루션만 IOProcess 스레드 풀을 사용하는 것입니다. 따라서 테이블 형식 인스턴스의 경우에는 이 항목에서 설명하는 PerNumaNode 속성이 의미가 없습니다.

이 항목에는 다음과 같은 섹션이 포함되어 있습니다.

• Thread Management in Analysis Services

• Thread Pool Property Reference

• Set GroupAffinity to affinitize IO threads to logical processors in a processor group

• Set PerNumaNode to create multiple IOProcess thread pools affinitized to a NUMA node

• Determine current thread pool settings

• Dependent or Related Properties

• About MSMDSRV.INI

[!참고]

NUMA 시스템의 테이블 형식 배포는 이 항목의 범위를 벗어납니다. 테이블 형식 솔루션을 NUMA 시스템에 성공적으로 배포할 수 있지만 테이블 형식 모델에 사용되는 메모리 내 데이터베이스 기술의 성능 특성으로 인해 고도로 확장된 아키텍처에서는 이에 대한 이점이 제한적일 수 있습니다. 자세한 내용은 Analysis Services 사례 연구: 대규모 상용 솔루션에서 테이블 형식 모델 사용(영문)및 테이블 형식 솔루션 하드웨어 크기 조정(영문)을 참조하세요.

Analysis Services의 스레드 관리

Analysis Services는 다중 스레드를 사용해서 병렬로 실행되는 작업 수를 늘림으로써 사용 가능한 CPU 리소스의 활용도를 높입니다. 저장소 엔진은 다중 스레드로 지정됩니다. 저장소 엔진 내에서 실행되는 다중 스레드 작업의 예로는 병렬 개체 처리 또는 저장소 엔진에 밀어 넣은 불연속 쿼리 처리 또는 쿼리에서 요청된 데이터 값 반환이 포함됩니다. 수식 엔진은 수식이 평가하는 계산의 직렬 특성으로 인해 단일 스레드로 지정됩니다. 각 쿼리는 기본적으로 단일 스레드로 실행되며, 데이터를 요청하고 종종 저장소 엔진에서 데이터가 반환될 때까지 기다립니다. 쿼리 스레드는 실행하는 데 더 오래 걸리며, 전체 쿼리가 완료된 다음에만 해제됩니다.

기본적으로 SQL Server 2012 이상 버전에서 Analysis Services는 상위 버전의 Windows 및 SQL Server를 실행하는 시스템에서 최대 640개까지 사용 가능한 모든 논리적 프로세서를 사용합니다. msmdsrv.exe 프로세스는 시작 시 특정 프로세스 그룹에 할당되지만 시간이 지남에 따라 임의 프로세서 그룹의 임의 논리적 프로세스에서 스레드를 예약할 수 있습니다.

많은 수의 프로세서 사용으로 인해 발생하는 한 가지 부작용은 많은 수의 프로세서에서 쿼리 및 처리 부하가 분산되고 공유 데이터 구조에 대한 경합이 증가함에 따라 성능 저하 문제가 발생할 수 있다는 것입니다. 이 문제는 특히 NUMA 아키텍처를 사용하는 고성능 시스템에서 발생할 수 있지만, 동일한 하드웨어에서 데이터 사용량이 많은 응용 프로그램을 여러 개 실행하는 비NUMA 시스템에서도 이 문제가 발생할 수 있습니다.

이 문제를 줄이기 위해서는 Analysis Services 작업 유형 간의 선호도를 설정하고 그에 따라 특정 논리적 프로세서 집합을 설정할 수 있습니다. GroupAffinity 속성을 사용하면 Analysis Services에서 관리되는 각 스레드 풀 유형에 사용할 시스템 리소스를 지정하는 사용자 지정 선호도 마스크를 만들 수 있습니다.

사용자 지정 선호도는 여러 Analysis Services 작업 로드에 사용되는 5개 스레드 풀 중 어디에든 설정할 수 있습니다.

• 구문 분석 \ 짧은 풀은 짧은 요청에 대한 구문 분석 풀입니다. 단일 네트워크 메시지 내에 포함되는 요청은 짧은 요청으로 간주됩니다.

• 구문 분석 \ 긴 풀은 단일 네트워크 메시지 내에 포함되지 않는 다른 모든 요청에 대한 구문 분석 풀입니다.

  [!참고]

  어느 구문 분석 풀의 스레드라도 쿼리를 실행하는 데 사용될 수 있습니다. 빠른 검색 또는 취소 요청과 같이 신속하게 실행되는 쿼리는 일부 경우, 쿼리 스레드 풀 큐에 저장되는 대신 즉시 실행될 수 있습니다.

• 쿼리 풀은 스레드 풀 구문 분석으로 처리되지 않는 모든 요청을 실행하는 스레드 풀입니다. 이 스레드 풀의 스레드는 검색, MDX, DAX, DMX 및 DDL 명령과 같은 모든 유형의 작업을 실행합니다.

• IOProcess 풀은 다차원 엔진에서 저장소 엔진 쿼리와 연관된 IO 작업에 사용됩니다. 이러한 스레드에서 수행되는 작업은 다른 스레드에 대한 종속성이 없는 것으로 고려됩니다. 이러한 스레드는 일반적으로 파티션의 단일 세그먼트를 검사하고 세그먼트 데이터에 대한 필터링 및 집계를 수행합니다. IOProcess 스레드는 특히 NUMA 하드웨어 구성에 민감합니다. 따라서 이 스레드 풀에는 필요에 따라 성능을 조정하는 데 사용할 수 있는 PerNumaNode 구성 속성이 포함됩니다.

• 처리 풀은 집계, 인덱싱 및 커밋 작업을 포함하여 오래 걸리는 저장소 엔진 작업을 위한 풀입니다. ROLAP 저장소 모드에서도 처리 스레드 풀의 스레드가 사용됩니다.

[!참고]

Msmdsrv.ini의 VertiPaq 섹션에 스레드 풀 설정이 포함되어 있지만 VertiPaq\ThreadPool\GroupAffinity 및 ThreadPool\CPUs는 의도적으로 설명에서 제외했습니다. 이러한 속성은 현재 작동 가능하지 않으며, 이후에 사용할 수 있도록 예약되어 있습니다.

작업 수행에 필요한 경우 Analysis Services는 서비스 요청에 대해 최대 스레드 풀 한도를 초과하여 추가 스레드를 요청할 수 있습니다. 하지만 현재 스레드 수가 최대 한도보다 큰 경우, 스레드의 작업 수행이 완료되면 스레드가 스레드 풀로 반환되는 대신 단순히 종료됩니다.

[!참고]

최대 스레드 풀 수를 초과하는 것은 특정 교착 상태 조건이 발생하는 경우에만 호출되는 보호 장치입니다. 런어웨이 스레드가 최대값을 넘어 만들어지지 않도록 하기 위해 최대 한도에 도달한 이후에는 짧은 지연 후 스레드가 점진적으로 만들어집니다. 최대 스레드 수를 초과하면 태스크 실행 속도가 느려질 수 있습니다. 성능 카운터를 통해 스레드 수가 스레드 풀의 최대 크기를 정기적으로 넘음을 나타내는 경우, 이 성능 카운터를 스레드 풀 크기가 시스템에서 요청되는 동시성 수준에 비해 너무 작음을 나타내는 지표로 사용할 수 있습니다.

기본적으로 스레드 풀 크기는 Analysis Services에서 결정되며, 코어 수를 기반으로 합니다. 선택된 기본값은 서비스 시작 후 msmdsrv.log를 조사하여 확인할 수 있습니다. 한 가지 성능 튜닝 방법으로, 다른 속성뿐만 아니라 스레드 풀 크기를 늘려서 쿼리 또는 처리 성능을 향상시킬 수 있습니다.

스레드 풀 속성 참조

이 섹션에서는 각 Analysis Services 인스턴스의 msmdsrv.ini 파일에 있는 스레드 풀 속성에 대해 설명합니다. 이러한 속성의 하위 집합도 SQL Server Management Studio에 표시됩니다.

속성은 사전순으로 나열됩니다.

GroupAffinity를 설정하여 프로세서 그룹의 프로세서에 대한 스레드 선호도 설정

GroupAffinity는 고급 튜닝 목적으로 제공됩니다. GroupAffinity 속성을 사용하여 Analysis Services 스레드 풀과 특정 프로세서 사이의 선호도를 설정할 수 있습니다. 그러나 대부분의 설치에서 Analysis Services는 사용 가능한 논리적 프로세서를 모두 사용할 때 성능이 가장 뛰어납니다. 따라서 그룹 선호도는 기본적으로 지정되지 않습니다.

성능 테스트에서 CPU 최적화가 필요한 것으로 나타날 경우 Windows Server 리소스 관리자를 사용해서 논리적 프로세서와 서버 프로세스 사이의 선호도를 설정하는 등 조금 더 고급스러운 접근 방식을 고려해야 할 수 있습니다. 이러한 접근 방식은 개별 스레드 풀에 대해 사용자 지정 선호도를 정의하는 것보다 구현 및 관리가 간단할 수 있습니다.

이 방법으로 충분하지 않을 경우에는 스레드 풀에 대해 사용자 지정 선호도를 정의하여 정밀도를 높일 수 있습니다. 너무 넓은 프로세서 범위로 분산되는 스레드 풀로 인해 성능이 저하되는 대형 다중 코어 시스템(NUMA 또는 비NUMA)에서는 선호도 설정을 사용자 지정하는 것이 좋습니다. 논리적 프로세서가 64개 미만인 시스템에서도 GroupAffinity를 설정할 수 있지만 이 경우 성능 이점이 저하되고 오히려 성능이 감소할 수도 있습니다.

[!참고]

GroupAffinity는 Analysis Services에서 사용하는 코어 수를 제한하는 버전에 따라 제약을 받습니다. 시작 시 Analysis Services에서는 버전 정보와 GroupAffinity 속성을 사용하여 Analysis Services에서 관리되는 5개의 스레드 풀 각각에 대한 선호도 마스크를 계산합니다. Standard Edition에서는 최대 16개의 코어를 사용할 수 있습니다. 16개를 초과하는 코어가 포함된 대형 다중 코어 시스템에 Analysis Services Standard Edition을 설치하는 경우 Analysis Services에서는 16개의 코어만 사용됩니다. 이전 버전의 Enterprise 인스턴스를 업그레이드하는 경우 20개의 코어로 제한됩니다. 버전 및 라이선스에 대한 자세한 내용은 SQL Server 2012 라이선스 개요를 참조하십시오.

구문

값은 각 프로세서 그룹에 대한 16진수 값이며, 16진수는 Analysis Services가 지정된 스레드 풀에 대해 스레드를 할당할 때 처음 사용하도록 시도하는 논리적 프로세서를 나타냅니다.

논리적 프로세서에 대한 비트 마스크

단일 프로세서 그룹 내에 최대 64개의 논리적 프로세서를 포함할 수 있습니다. 비트 마스크는 스레드 풀에서 사용되는(또는 사용되지 않는) 그룹의 각 논리적 프로세서에 대해 1(또는 0)입니다. 비트 마스크를 계산한 다음에는 16진수 값을 GroupAffinity에 대한 값으로 계산합니다.

다중 프로세서 그룹

프로세서 그룹은 시스템 시작 시에 결정됩니다. GroupAffinity에는 쉼표로 구분된 목록의 각 프로세서 그룹에 대한 16진수 값이 사용됩니다. 다중 프로세서 그룹(고성능 시스템의 경우 최대 10개)이 지정된 경우, 0x0을 지정하여 개별 그룹을 무시할 수 있습니다. 예를 들어 4개의 프로세서 그룹(0, 1, 2, 3)이 포함된 시스템에서는 첫 번째 및 세 번째 값에 대해 0x0을 입력하여 그룹 0 및 2를 제외할 수 있습니다.

<GroupAffinity>0x0, 0xFF, 0x0, 0xFF</GroupAffinity>

프로세서 선호도 마스크 계산 단계

msmdsrv.ini 또는 SQL Server Management Studio의 서버 속성 페이지에서 GroupAffinity를 설정할 수 있습니다.

1. 프로세서 및 프로세서 그룹 수 결정

   winsysinternals에서 Coreinfo 유틸리티를 다운로드할 수 있습니다.

   논리적 프로세서에서 그룹 맵 섹션으로 이 정보를 가져오려면 coreinfo를 실행합니다. 각 논리적 프로세서에 대해 별도의 행이 생성됩니다.

2. 오른쪽에서 왼쪽으로의 프로세서 순서: 7654 3210

   예제에는 프로세서가 8개(0~7)만 표시되지만 프로세서 그룹은 최대 64개의 논리적 프로세서를 포함할 수 있으며, 엔터프라이즈급 Windows 서버에는 최대 10개의 프로세서 그룹이 포함될 수 있습니다.

3. 사용하려는 프로세서 그룹에 대한 비트 마스크 계산

   7654 3210

   논리적 프로세서를 제외 또는 포함시키려는지 여부에 따라 숫자를 0 또는 1로 바꿉니다. 8개 프로세서가 포함된 시스템에서는 Analysis Services에 대해 프로세서 7, 6, 5, 4 및 1을 사용하려고 한 것처럼 계산이 표시될 수 있습니다.

   1111 0010

4. 이진 숫자를 16진수 값으로 변환

   계산기 또는 변환 도구를 사용해서 이진 숫자를 16진수 값으로 변환합니다. 이 예에서 1111 0010은 0xF2로 변환됩니다.

5. GroupAffinity 속성에 16진수 값을 입력합니다.

   msmdsrv.ini 또는 Management Studio의 서버 속성 페이지에서 GroupAffinity를 4단계에서 계산된 값으로 설정합니다.

중요
GroupAffinity 설정은 여러 단계가 포함된 수동 작업입니다. GroupAffinity를 계산할 때는 계산을 신중하게 확인해야 합니다. 전체 마스크가 잘못된 경우 Analysis Services가 오류를 반환하지만 올바른 설정과 잘못된 설정이 조합된 경우 Analysis Services에서 속성이 무시됩니다. 예를 들어 비트 마스크에 추가 값이 포함된 경우 Analysis Services가 설정을 무시하고, 시스템에서 모든 프로세서를 사용합니다. 이 동작이 발생할 때 오류나 경고가 발생하지 않지만, msmdsrv.log 파일을 확인하여 선호도가 실제로 어떻게 설정되었는지 알아볼 수 있습니다.

NUMA 노드에서 프로세서에 대한 IO 스레드 선호도를 설정하기 위한 PerNumaNode 설정

다차원 Analysis Services 인스턴스에서는 IOProcess 스레드 풀에서 PerNumaNode를 설정하여 스레드 예약 및 실행을 추가로 최적화할 수 있습니다. GroupAffinity는 제공된 스레드 풀에 사용할 논리적 프로세서 집합을 식별하지만 PerNumaNode는 추가적으로 허용된 논리적 프로세서의 일부 하위 집합으로 선호도가 설정된 다중 스레드 풀을 만들지 여부를 지정하여 한 단계 더 나아갑니다.

[!참고]

Windows Server 2012에서 작업 관리자를 사용하여 컴퓨터의 NUMA 노드 수를 확인할 수 있습니다. 작업 관리자의 성능 탭에서 CPU를 선택한 다음 그래프 영역을 마우스 오른쪽 단추로 클릭하면 NUMA 노드 수가 표시됩니다. 또는 Windows Sysinternals에서 Coreinfo 유틸리티를 다운로드하고 coreinfo –n을 실행하여 NUMA 노드 수와 각 노드의 논리적 프로세서 수를 반환합니다.

PerNumaNode의 올바른 값은 이 항목의 Thread Pool Property Reference 섹션에 설명된 대로 -1, 0, 1, 2입니다.

기본값(권장)

NUMA 노드가 포함된 시스템에서는 기본 설정 PerNumaNode=-1을 사용해서 Analysis Services가 노드 수에 따라 스레드 풀의 수와 스레드 선호도를 조정하도록 허용하는 것이 좋습니다. 시스템에 4개 미만의 노드가 포함된 경우 Analysis Services는 PerNumaNode=0으로 설명된 동작을 구현합니다. PerNumaNode=1은 노드가 4개 이상인 시스템에서 사용됩니다.

값 선택

다른 유효한 값을 사용하기 위해 기본값을 재정의할 수도 있습니다.

PerNumaNode=0 설정

NUMA 노드가 무시됩니다. IOProcess 스레드 풀이 하나만 있고 이 스레드 풀의 모든 스레드는 모든 논리적 프로세서로 선호도가 설정됩니다. 기본적으로(PerNumaNode=-1) 이 설정은 컴퓨터에 4개 미만의 NUMA 노드가 있는 경우 작동 가능한 설정입니다.

PerNumaNode=1 설정

IOProcess 스레드 풀이 각 NUMA 노드에 대해 만들어집니다. 스레드 풀을 별도로 지정하면 NUMA 노드의 로컬 캐시와 같이 로컬 리소스에 대한 액세스 조정 성능이 향상됩니다.

PerNumaNode=2 설정

이 설정은 많은 Analysis Services 작업을 실행하는 고성능 시스템을 위한 설정입니다. 이 속성은 IOProcess 스레드 풀 선호도를 가장 세분화된 수준으로 설정해서 논리적 프로세서 수준에서 개별 스레드 풀을 만들고 선호도를 설정합니다.

다음 예에서, NUMA 노드 4개와 논리적 프로세서 32개가 포함된 시스템에서 PerNumaNode를 2로 설정하면 IOProcess 스레드 풀이 32개가 됩니다. 처음 8개 스레드 풀의 스레드는 NUMA 노드 0의 모든 논리적 프로세서로 선호도가 설정되지만 이상적인 프로세서 설정은 0, 1, 2부터 최대 7까지입니다. 다음 8개 스레드 풀은 NUMA 노드 1의 모든 논리적 프로세서로 선호도가 설정되며, 이상적인 프로세서 설정은 8, 9, 10부터 최대 15까지입니다.

이러한 선호도 수준에서 스케줄러는 항상 선호되는 NUMA 노드 내에서 이상적인 논리적 프로세서를 먼저 사용하도록 시도합니다. 논리적 프로세서를 사용할 수 없으면, 스케줄러가 동일한 노드 내에서 또는 동일한 프로세서 그룹 내에서(다른 스레드를 사용할 수 없는 경우) 다른 프로세서를 선택합니다. 자세한 내용 및 예제를 보려면 Analysis Services 2012 구성 설정(Wordpress 블로그)을 참조하십시오.

IOProcess 스레드 간 작업 분산

PerNumaNode 속성을 설정할지 여부를 고려할 때 IOProcess 스레드가 사용되는 방식을 알고 있으면 보다 합리적인 결정을 내릴 수 있습니다.

이전에 설명한 대로 IOProcess 풀은 다차원 엔진에서 저장소 엔진 쿼리와 연관된 IO 작업에 사용됩니다.

세그먼트가 검색될 때 엔진은 세그먼트가 속한 파티션을 식별하고 해당 파티션이 사용하는 스레드 풀에 세그먼트 작업을 대기시키려고 합니다. 일반적으로 파티션에 속한 모든 세그먼트가 동일한 스레드 풀에 작업을 대기시킵니다. NUMA 시스템에서는 파티션에 대한 모든 검색에 NUMA 노드에 로컬로 할당되는 파일 시스템 캐시의 메모리가 사용되기 때문에 이 동작이 특히 유용합니다.

다음 시나리오에서는 경우에 따라 NUMA 시스템에서 쿼리 성능을 향상시킬 수 있는 조정 방법을 제안합니다.

• 분할되지 않은(예를 들어 파티션이 하나뿐인) 측정값 그룹의 경우 파티션 수를 늘립니다. 파티션을 하나만 사용하면 엔진이 항상 하나의 스레드 풀(스레드 풀 0)에 작업을 대기시킵니다. 파티션을 더 추가하면 엔진이 추가 스레드 풀을 사용할 수 있습니다.

  또는 추가 파티션을 만들 수 없는 경우 스레드 풀 0에서 사용 가능한 스레드 수를 늘리는 방법으로 PerNumaNode=0을 설정해 보십시오.

• 세그먼트 검색이 여러 파티션에 균등하게 분산되어 있는 데이터베이스의 경우 PerNumaNode를 1 또는 2로 설정하면 시스템에서 사용하는 전체적인 IOProcess 스레드 풀 수가 증가하기 때문에 쿼리 성능이 향상될 수 있습니다.

• 여러 파티션이 있지만 하나만 많이 검색되는 솔루션의 경우 PerNumaNode=0을 설정하여 성능이 향상되는지 확인합니다.

파티션 검색과 차원 검색 모두 IOProcess 스레드 풀을 사용하지만 차원 검색만 스레드 풀 0을 사용합니다. 이로 인해 해당 스레드 풀에서 약간 균등하지 않은 부하가 발생할 수 있지만 차원 검색은 매우 빠르고 자주 발생하지 않으므로 이러한 불균형은 일시적입니다.

[!참고]

서버 속성을 변경하는 경우 구성 옵션이 현재 인스턴스에서 실행되는 모든 데이터베이스에 적용됩니다. 가장 중요한 데이터베이스나 대다수의 데이터베이스에 유용한 설정을 선택하십시오. 데이터베이스 수준에서 프로세서 선호도를 설정할 수 없으며 개별 파티션과 특정 프로세서 사이의 선호도를 설정할 수 없습니다.

작업 아키텍처에 대한 자세한 내용은 SQL Server 2008 Analysis Services 성능 가이드의 2.2 섹션을 참조하십시오.

종속되었거나 관련된 속성

Analysis Services 작업 가이드의 2.4 섹션에 설명된 대로 처리 스레드 풀을 늘리면 CoordinatorQueryMaxThreads 설정뿐만 아니라 CoordinatorExecutionMode 설정에 증가한 스레드 풀 크기를 모두 사용할 수 있도록 하는 값이 포함되었는지 확인해야 합니다.

Analysis Services는 처리 또는 쿼리 요청을 완료하는 데 필요한 데이터 수집을 위해 코디네이터 스레드를 사용합니다. 코디네이터는 각 파티션에 대해 먼저 처리되어야 하는 최대 1개의 작업을 큐에 넣습니다. 이러한 각 작업은 파티션에서 검색되어야 하는 총 세그먼트 수에 따라 계속해서 추가 작업을 큐에 넣습니다.

CoordinatorExecutionMode는 기본값이 코어당 병렬 처리 작업이 4개로 제한됨을 의미하는 -4이며, 저장소 엔진의 하위 큐브 요청에 의해 병렬로 실행할 수 있는 총 코디네이터 작업 수를 제한합니다.

CoordinatorQueryMaxThreads는 기본값이 16이며, 각 파티션에서 병렬로 실행될 수 있는 세그먼트 작업 수를 제한합니다.

현재 스레드 풀 설정 확인

각 서비스 시작 시 Analysis Services는 최소 및 최대 스레드, 프로세서 선호도 마스크 및 동시성을 포함하여 현재 스레드 풀 설정을 msmdsrv.log 파일로 출력합니다.

다음 예는 로그 파일에서 하이퍼스레딩이 지원되는 4코어 시스템에서 쿼리 스레드 풀의 기본 설정(MinThread=0, MaxThread=0, Concurrency=2)을 보여주는 일부를 가져온 것입니다. 선호도 마스크는 8개 논리적 프로세서를 나타내는 0xFF입니다. 여기에서는 마스크에 선행 0이 있는 것을 알 수 있습니다. 선행 0은 무시할 수 있습니다.

"10/28/2013 9:20:52 AM) Message: The Query thread pool now has 1 minimum threads, 16 maximum threads, and a concurrency of 16. Its thread pool affinity mask is 0x00000000000000ff. (Source: \\?\C:\Program Files\Microsoft SQL Server\MSAS11.MSSQLSERVER\OLAP\Log\msmdsrv.log, Type: 1, Category: 289, Event ID: 0x4121000A)"

MinThread 및 MaxThread 설정을 위한 알고리즘에는 시스템 구성, 특히 프로세서 수가 포함됩니다. 다음 블로그 게시물에서는 이러한 값이 계산되는 방법에 대해 자세히 설명합니다. Analysis Services 2012 구성 설정(Wordpress 블로그). 이러한 설정 및 동작은 이후 릴리스에서의 조정에 따라 변경될 수 있습니다.

다음 목록에서는 다양한 프로세서 조합에 대한 다른 선호도 마스크 설정의 예를 보여 줍니다.

• 8코어 시스템에서 프로세서 3-2-1-0에 대한 선호도 설정은 비트 마스크: 00001111, 및 16 진수 값: 0xF를 지정합니다.

• 8코어 시스템에서 프로세서 7-6-5-4에 대한 선호도 설정은 비트 마스크: 11110000, 및 16 진수 값: 0xF0을 지정합니다.

• 8코어 시스템에서 프로세서 5-4-3-2에 대한 선호도 설정은 비트 마스크: 00111100, 및 16 진수 값: 0x3C를 지정합니다.

• 8코어 시스템에서 프로세서 7-6-1-0에 대한 선호도 설정은 비트 마스크: 11000011, 및 16 진수 값: 0xC3을 지정합니다.

다중 프로세서 그룹을 포함하는 시스템에서는 쉼표로 구분된 목록의 각 그룹에 대해 별도의 선호도 마스크가 생성됩니다.

MSMDSRV.INI 정보

msmdsrv.ini 파일은 Analysis Services 인스턴스에 대한 구성 설정을 포함하므로 해당 인스턴스에서 실행되는 모든 데이터베이스에 영향을 미칩니다. 다른 모든 데이터베이스를 제외하고 한 데이터베이스의 성능만 최적화하기 위해 서버 구성 속성을 사용할 수는 없습니다. 그러나 Analysis Services의 인스턴스를 여러 개 설치하고 유사한 특성이나 작업을 공유하는 데이터베이스에 유용한 속성을 사용하도록 각 인스턴스를 구성할 수 있습니다.

모든 서버 구성 속성은 msmdsrv.ini 파일에 포함되어 있습니다. 수정 가능성이 높은 속성 하위 집합은 SSMS와 같은 관리 도구에도 표시됩니다.

msmdsrv.ini 내용은 Analysis Services의 테이블 형식 및 다차원 인스턴스 모두 동일합니다. 하지만 일부 설정은 한 가지 모드에만 적용됩니다. 서버 모드에 따른 동작의 차이는 속성 참조 설명서에서 확인할 수 있습니다.

[!참고]

속성 설정 방법은 Analysis Services에서 서버 속성 구성을 참조하십시오.

참고 항목

관련 자료

프로세서 및 스레드 정보

다중 프로세서

프로세서 그룹

SQL Server 2012의 Analysis Services 스레드 풀 변경 사항

Analysis Services 2012 구성 설정(Wordpress 블로그)

64개 이상의 프로세서가 포함된 시스템 지원

SQL Server 2008 R2 Analysis Services 작업 가이드