クエリ インターリーブ
適用対象:
SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium
クエリ インターリーブは表形式モードのシステム構成であり、コンカレンシーの高いシナリオでクエリのパフォーマンスを向上させることができます。 既定では、Analysis Services 表形式エンジンは、CPU に関して先入れ先出し (FIFO) の方法で動作します。 たとえば、FIFO を使用すると、1 つのリソースが高価で低速なストレージ エンジン クエリを受信し、その後に 2 つの高速クエリを受け取った場合、コストの高いクエリが完了するのを待って高速クエリがブロックされる可能性があります。 この動作を次の図に示します。この図では、Q1、Q2、Q3 がそれぞれのクエリ、期間、CPU 時間として示されています。
クエリ バイアスが 短いクエリ インターリーブを使用すると、同時実行クエリで CPU リソースを共有できます。つまり、低速クエリの背後で高速クエリがブロックされません。 3 つのクエリをすべて完了するのにかかる時間はまだ同じですが、この例の Q2 と Q3 は最後までブロックされません。 クエリのバイアスが短いということは、特定の時点で各クエリが既に消費している CPU の量によって定義される高速なクエリを意味し、実行時間の長いクエリよりも高い割合のリソースを割り当てることができるということです。 次の図では、Q2 クエリと Q3 クエリは 高速 であると見なされ、Q1 よりも多くの CPU が割り当てられています。
クエリ インターリーブは、分離して実行されるクエリに対するパフォーマンスへの影響がほとんどまたはまったくないことを目的としています。1 つのクエリでは、FIFO モデルと同じ量の CPU を引き続き使用できます。
重要な考慮事項
クエリ インターリーブがシナリオに適しているかどうかを判断する前に、次の点に注意してください。
- クエリ インターリーブは、インポート モデルにのみ適用されます。 DirectQuery モデルには影響しません。
- クエリ インターリーブでは、VertiPaq ストレージ エンジン クエリによって消費される CPU のみが考慮されます。 数式エンジンの操作には適用されません。
- 1 つの DAX クエリで、複数の VertiPaq ストレージ エンジン クエリが発生する可能性があります。 DAX クエリは、そのストレージ エンジン クエリによって消費される CPU に基づいて 、高速 または 低速 と見なされます。 DAX クエリは測定単位です。
- 更新操作は、既定でクエリ インターリーブから保護されます。 実行時間の長い更新操作は、実行時間の長いクエリとは異なる方法で分類されます。
構成
クエリ インターリーブを構成するには、 Threadpool\SchedulingBehavior プロパティを 設定します。 このプロパティは、次の値で指定できます。
| 値 | 説明 |
|---|---|
| -1 | 自動。 エンジンによってキューの種類が選択されます。 |
| 0 (SSAS 2019 の既定値) | 先入れ先出し (FIFO)。 |
| 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>
重要
サーバー インスタンスの再起動が必要です。 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 不足の場合にのみ適用されます。 たとえば、1 つのクエリが特定の時点でシステムで実行されている唯一のクエリである場合、減衰しているかどうかに関係なく、使用可能なすべてのコアを使用できます。
各クエリには、多くのストレージ エンジン ジョブが必要な場合があります。 減衰したクエリのプール内のコアが使用可能になると、スケジューラは、カレンダーの経過時間に基づいて最も古い実行中のクエリをチェックし、その最大コア エンタイトルメント (MCE) を既に使用しているかどうかを確認します。 いいえの場合、その次のジョブが実行されます。 "はい" の場合、次に最も古いクエリが評価されます。 クエリ MCE は、既に使用されている減衰間隔の数によって決まります。 使用される減衰間隔ごとに、次の表に示すアルゴリズムに基づいて MCE が減少します。 これは、クエリが完了するか、タイムアウトするか、MCE が 1 つのコアに減るまで続行されます。
次の例では、システムに 32 個のコアがあり、システムの CPU に負荷がかかっています。
ReservedComputeForFastQueries は 60 (60%) です。
- 高速クエリ用に 20 コア (19.2 切り上げ) が予約されています。
- 残りの 12 個のコアは、減衰したクエリに割り当てられます。
DecayIntervalCPUTime は 60,000 (CPU 時間の 1 分) です。
クエリのライフサイクルは、タイムアウトまたは完了しない限り、次のようになります。
| 段階 | Status | 実行/スケジュール | 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 を超えるコアが割り当てされません。 現在、すべてのコアがそれぞれの MCEs 内のクエリで使用されている場合、他のクエリはコアが使用可能になるまで待機します。 コアが使用可能になると、カレンダーの経過時間に基づく最も古い権利付きクエリが取得されます。 MCE は圧力下のキャップです。どの時点でもコアの数は保証されません。
こちらもご覧ください
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示