쿼리 인터리빙
적용 대상:
SQL Server Analysis Services Azure Analysis Services 패브릭/Power BI Premium
쿼리 인터리빙은 동시성이 높은 시나리오에서 쿼리 성능을 향상시킬 수 있는 테이블 형식 모드 시스템 구성입니다. 기본적으로 Analysis Services 테이블 형식 엔진은 CPU와 관련하여 FIFO(선점) 방식으로 작동합니다. 예를 들어 FIFO를 사용하면 비용이 많이 들고 스토리지 엔진 쿼리가 느릴 수 있는 리소스 하나가 수신된 다음 두 개의 빠른 쿼리가 뒤에 오면 비용이 많이 드는 쿼리가 완료되기를 기다리는 빠른 쿼리가 차단될 수 있습니다. 이 동작은 다음 다이어그램에 나와 있습니다. 이 다이어그램은 Q1, Q2 및 Q3을 각 쿼리, 해당 기간 및 CPU 시간으로 보여 줍니다.
짧은 쿼리 바이어스를 사용하여 쿼리 인터리빙을 사용하면 동시 쿼리가 CPU 리소스를 공유할 수 있습니다. 즉, 느린 쿼리 뒤에 빠른 쿼리가 차단되지 않습니다. 세 쿼리를 모두 완료하는 데 걸리는 시간은 거의 동일하지만 예제에서는 Q2 및 Q3이 끝날 때까지 차단되지 않습니다. 짧은 쿼리 편향은 각 쿼리가 특정 시점에 이미 사용한 CPU의 양으로 정의된 빠른 쿼리를 의미하며, 장기 실행 쿼리보다 리소스 비율이 더 높습니다. 다음 다이어그램에서 Q2 및 Q3 쿼리는 빠른 것으로 간주되며 1분기보다 더 많은 CPU를 할당합니다.
쿼리 인터리빙은 격리된 상태로 실행되는 쿼리에 성능에 거의 또는 전혀 영향을 주지 않습니다. 단일 쿼리는 FIFO 모델과 마찬가지로 CPU를 계속 사용할 수 있습니다.
중요 고려 사항
쿼리 인터리빙이 시나리오에 적합한지 확인하기 전에 다음 사항에 유의하세요.
- 쿼리 인터리빙은 가져오기 모델에만 적용됩니다. DirectQuery 모델에는 영향을 주지 않습니다.
- 쿼리 인터리빙은 VertiPaq 스토리지 엔진 쿼리에서 사용하는 CPU만 고려합니다. 수식 엔진 작업에는 적용되지 않습니다.
- 단일 DAX 쿼리로 인해 여러 VertiPaq 스토리지 엔진 쿼리가 발생할 수 있습니다. DAX 쿼리는 스토리지 엔진 쿼리에서 사용하는 CPU에 따라 빠르 거나 느린 것으로 간주됩니다. DAX 쿼리는 측정 단위입니다.
- 새로 고침 작업은 기본적으로 쿼리 인터리빙으로부터 보호됩니다. 장기 실행 새로 고침 작업은 장기 실행 쿼리와 다르게 분류됩니다.
구성
쿼리 인터리빙을 구성하려면 Threadpool\SchedulingBehavior 속성을 설정합니다. 이 속성은 다음 값으로 지정할 수 있습니다.
| 값 | 설명 |
|---|---|
| -1 | 자동. 엔진은 큐 유형을 선택합니다. |
| 0(SSAS 2019의 기본값) | FIFO(First out)의 첫 번째 항목입니다. |
| 1 | 짧은 쿼리 바이어스입니다. 엔진은 빠른 쿼리를 위해 압력을 받을 때 장기 실행 쿼리를 점진적으로 제한합니다. |
| 3(Azure AS, Power BI, SSAS 2022 이상에 대한 기본값) | 빠른 취소가 있는 짧은 쿼리 바이어스입니다. 동시성이 높은 시나리오에서 사용자 쿼리 응답 시간을 개선합니다. Azure AS, Power BI, SSAS 2022 이상에만 적용됩니다. |
현재 SchedulingBehavior 속성은 XMLA를 사용하여 설정할 수 있습니다. SQL Server Management Studio 다음 XMLA 코드 조각은 SchedulingBehavior 속성을 짧은 쿼리 바이어스인 1로 설정합니다.
<Alter AllowCreate="true" ObjectExpansion="ObjectProperties" xmlns="http://schemas.microsoft.com/analysisservices/2003/engine">
<Object />
<ObjectDefinition>
<Server xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ddl2="http://schemas.microsoft.com/analysisservices/2003/engine/2" xmlns:ddl2_2="http://schemas.microsoft.com/analysisservices/2003/engine/2/2" xmlns:ddl100_100="http://schemas.microsoft.com/analysisservices/2008/engine/100/100" xmlns:ddl200="http://schemas.microsoft.com/analysisservices/2010/engine/200" xmlns:ddl200_200="http://schemas.microsoft.com/analysisservices/2010/engine/200/200" xmlns:ddl300="http://schemas.microsoft.com/analysisservices/2011/engine/300" xmlns:ddl300_300="http://schemas.microsoft.com/analysisservices/2011/engine/300/300" xmlns:ddl400="http://schemas.microsoft.com/analysisservices/2012/engine/400" xmlns:ddl400_400="http://schemas.microsoft.com/analysisservices/2012/engine/400/400" xmlns:ddl500="http://schemas.microsoft.com/analysisservices/2013/engine/500" xmlns:ddl500_500="http://schemas.microsoft.com/analysisservices/2013/engine/500/500">
<ID>myserver</ID>
<Name>myserver</Name>
<ServerProperties>
<ServerProperty>
<Name>ThreadPool\SchedulingBehavior</Name>
<Value>1</Value>
</ServerProperty>
</ServerProperties>
</Server>
</ObjectDefinition>
</Alter>
중요
서버 instance 다시 시작해야 합니다. Azure Analysis Services 서버를 일시 중지한 다음 다시 시작하여 효과적으로 다시 시작해야 합니다.
추가 속성
대부분의 경우 SchedulingBehavior는 설정해야 하는 유일한 속성입니다. 다음 추가 속성에는 짧은 쿼리 바이어스가 있는 대부분의 시나리오에서 작동해야 하는 기본값이 있지만 필요한 경우 변경할 수 있습니다. SchedulingBehavior 속성을 설정하여 쿼리 인터리빙을 사용하도록 설정하지 않는 한 다음 속성은 영향을 주지 않습니다 .
ReservedComputeForFastQueries - 빠른 쿼리에 대한 예약된 논리 코어 수를 설정합니다. 모든 쿼리는 특정 양의 CPU를 사용했기 때문에 감소할 때까지 빠르게 간주됩니다. ReservedComputeForFastQueries는 0에서 100 사이의 정수입니다. 기본값은 75입니다.
ReservedComputeForFastQueries에 대한 측정 단위는 코어의 백분율입니다. 예를 들어 코어가 20개인 서버의 값 80은 빠른 쿼리를 위해 16개의 코어를 예약하려고 시도합니다(새로 고침 작업은 수행되지 않음). ReservedComputeForFastQueries는 가장 가까운 정수의 코어로 반올림합니다. 이 속성 값을 50 미만으로 설정하지 않는 것이 좋습니다. 이는 빠른 쿼리가 박탈될 수 있고 기능의 전반적인 디자인과 반대되기 때문입니다.
DecayIntervalCPUTime - 쿼리가 감쇠되기 전에 소비하는 CPU 시간을 밀리초 단위로 나타내는 정수입니다. 시스템이 CPU 압력을 받고 있는 경우 감쇠된 쿼리는 빠른 쿼리를 위해 예약되지 않은 나머지 코어로 제한됩니다. 기본값은 60,000입니다. 경과된 달력 시간이 아닌 CPU 시간의 1분을 나타냅니다.
ReservedComputeForProcessing - 각 처리(데이터 새로 고침) 작업에 대한 예약된 논리 코어 수를 설정합니다. 속성 값은 0에서 100 사이의 정수이며 기본값은 75입니다. 값은 ReservedComputeForFastQueries 속성에 의해 결정된 코어의 백분율을 나타냅니다. 값이 0이면 처리 작업에 쿼리와 동일한 쿼리 인터리빙 논리가 적용되므로 감쇠될 수 있습니다.
처리 작업이 수행되지 않는 동안 ReservedComputeForProcessing은 적용되지 않습니다. 예를 들어 값이 80인 20개 코어가 있는 서버의 ReservedComputeForFastQueries는 빠른 쿼리를 위해 16개의 코어를 예약합니다. 값이 75인 ReservedComputeForProcessing은 새로 고침 작업을 위해 16개 코어 중 12개만 예약하며, 처리 작업이 실행되고 CPU를 사용하는 동안 빠른 쿼리에 대해 4개만 남습니다. 아래 의 감쇠된 쿼리 섹션에 설명된 대로 나머지 4개 코어(빠른 쿼리 또는 처리 작업을 위해 예약되지 않음)는 여전히 빠른 쿼리 및 유휴 상태인 경우 처리에 사용됩니다.
이러한 추가 속성은 ResourceGovernance 속성 노드 아래에 있습니다. SQL Server Management Studio 다음 예제 XMLA 코드 조각은 DecayIntervalCPUTime 속성을 기본값보다 낮은 값으로 설정합니다.
<Alter AllowCreate="true" ObjectExpansion="ObjectProperties" xmlns="http://schemas.microsoft.com/analysisservices/2003/engine">
<Object />
<ObjectDefinition>
<Server xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ddl2="http://schemas.microsoft.com/analysisservices/2003/engine/2" xmlns:ddl2_2="http://schemas.microsoft.com/analysisservices/2003/engine/2/2" xmlns:ddl100_100="http://schemas.microsoft.com/analysisservices/2008/engine/100/100" xmlns:ddl200="http://schemas.microsoft.com/analysisservices/2010/engine/200" xmlns:ddl200_200="http://schemas.microsoft.com/analysisservices/2010/engine/200/200" xmlns:ddl300="http://schemas.microsoft.com/analysisservices/2011/engine/300" xmlns:ddl300_300="http://schemas.microsoft.com/analysisservices/2011/engine/300/300" xmlns:ddl400="http://schemas.microsoft.com/analysisservices/2012/engine/400" xmlns:ddl400_400="http://schemas.microsoft.com/analysisservices/2012/engine/400/400" xmlns:ddl500="http://schemas.microsoft.com/analysisservices/2013/engine/500" xmlns:ddl500_500="http://schemas.microsoft.com/analysisservices/2013/engine/500/500">
<ID>myserver</ID>
<Name>myserver</Name>
<ServerProperties>
<ServerProperty>
<Name>ResourceGovernance\DecayIntervalCPUTime</Name>
<Value>15000</Value>
</ServerProperty>
</ServerProperties>
</Server>
</ObjectDefinition>
</Alter>
감쇠된 쿼리
이 섹션에 설명된 제약 조건은 시스템이 CPU 압력을 받고 있는 경우에만 적용됩니다. 예를 들어 단일 쿼리는 지정된 시간에 시스템에서 실행되는 유일한 쿼리인 경우 감쇠 여부에 관계없이 사용 가능한 모든 코어를 사용할 수 있습니다.
각 쿼리에는 많은 스토리지 엔진 작업이 필요할 수 있습니다. 감소된 쿼리에 대한 풀의 코어를 사용할 수 있게 되면 스케줄러는 경과된 달력 시간에 따라 가장 오래된 실행 중인 쿼리를 검사 MCE(최대 코어 권한)를 이미 사용했는지 확인합니다. 아니요이면 다음 작업이 실행됩니다. 그렇다면 다음으로 오래된 쿼리가 평가됩니다. 쿼리 MCE는 이미 사용한 감쇠 간격 수에 따라 결정됩니다. 사용된 각 감쇠 간격에 대해 MCE는 아래 표에 표시된 알고리즘에 따라 감소됩니다. 쿼리가 완료, 시간 초과 또는 MCE가 단일 코어로 축소될 때까지 계속됩니다.
다음 예제에서는 시스템에 32개의 코어가 있고 시스템의 CPU가 압력을 받고 있습니다.
ReservedComputeForFastQueries는 60(60%)입니다.
- 20개 코어(19.2 반올림)는 빠른 쿼리를 위해 예약되어 있습니다.
- 나머지 12개 코어는 감쇠된 쿼리에 할당됩니다.
DecayIntervalCPUTime은 60,000(CPU 시간 1분)입니다.
쿼리의 수명 주기는 시간 초과 또는 완료되지 않는 한 다음과 같습니다.
| 단계 | 상태 | 실행/예약 | MCE |
|---|---|---|---|
| 0 | 빠름 | MCE는 20개 코어(빠른 쿼리용으로 예약됨)입니다. 쿼리는 20개의 예약된 코어에서 다른 빠른 쿼리와 관련하여 FIFO 방식으로 실행됩니다. CPU 시간의 1분의 감쇠 간격이 사용됩니다. |
20 = MIN(32/2˄0, 20) |
| 1 | 부식 | MCE는 12개 코어로 설정됩니다(빠른 쿼리를 위해 예약되지 않은 나머지 코어 12개). 작업은 MCE까지의 가용성에 따라 실행됩니다. CPU 시간의 1분의 감쇠 간격이 사용됩니다. |
12 = MIN(32/2˄1, 12) |
| 2 | 부식 | MCE는 8개 코어(총 코어 32개 중 분기)로 설정됩니다. 작업은 MCE까지의 가용성에 따라 실행됩니다. CPU 시간의 1분의 감쇠 간격이 사용됩니다. |
8 = MIN(32/2˄2, 12) |
| 3 | 부식 | MCE는 4코어로 설정됩니다. 작업은 MCE까지의 가용성에 따라 실행됩니다. CPU 시간의 1분의 감쇠 간격이 사용됩니다. |
4 = MIN(32/2˄3, 12) |
| 4 | 부식 | MCE는 2코어로 설정됩니다. 작업은 MCE까지의 가용성에 따라 실행됩니다. CPU 시간의 1분의 감쇠 간격이 사용됩니다. |
2 = MIN(32/2˄4, 12) |
| 5 | 부식 | MCE는 1코어로 설정됩니다. 작업은 MCE까지의 가용성에 따라 실행됩니다. 쿼리가 아래쪽에 있으므로 감쇠 간격이 적용되지 않습니다. 최소 1코어에 도달했기 때문에 더 이상 감소하지 않습니다. |
1 = MIN(32/2˄5, 12) |
시스템이 CPU 압력을 받고 있는 경우 각 쿼리에는 MCE보다 더 이상 코어가 할당되지 않습니다. 모든 코어가 현재 해당 MCE 내의 쿼리에서 사용되는 경우 다른 쿼리는 코어를 사용할 수 있게 될 때까지 기다립니다. 코어를 사용할 수 있게 되면 경과된 달력 시간에 따라 가장 오래된 자격 쿼리가 선택됩니다. MCE는 압력을 받는 상한입니다. 특정 시점의 코어 수를 보장하지는 않습니다.
추가 정보
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기