クエリ インターリーブ

適用対象: SQL Server Analysis Services Azure Analysis Services Power BI Premium

クエリ インターリーブは、コンカレンシーの高いシナリオでクエリのパフォーマンスを向上させる表形式モードのシステム構成です。 既定では、Analysis Servicesテーブル エンジンは、CPU に関して先入れ先出し (FIFO) 形式で動作します。 つまり、たとえば、1 つのリソースのコストが高く、場合によっては低速のストレージ エンジン クエリが受信され、その後に 2 つの高速クエリが続く場合、高速クエリは、コストのかかるクエリが完了するのを待機してブロックされる可能性があります。 これは次の図に示されています。各クエリ、期間、CPU 時間として Q1、Q2、Q3 を示します。

先入れ先出し

短いクエリ バイアスによるクエリ インターリーブ を使用すると、 同時実行クエリで CPU リソースを共有できます。 つまり、高速クエリは低速クエリの背後でブロックされません。 3 つのクエリの完了にかかる時間はまだ同じですが、この例では Q2 と Q3 は最後までブロックされません。 短いクエリ バイアスは、特定の時点で各クエリが既に消費している CPU の量によって定義される高速クエリを意味し、実行時間の長いクエリよりも高い割合のリソースを割り当て可能です。 次の図では、Q2 クエリと Q3 クエリは高速と見なされ、Q1 よりも多くの CPU が割り当てられていると見なされます。

短いクエリ バイアス

クエリインターリーブは、分離して実行されるクエリに対するパフォーマンスへの影響をほとんどまたは全く持たねない目的です。1 つのクエリでも、FIFO モデルと同じ量の CPU を消費できます。

重要な考慮事項

クエリインターリーブがシナリオに適切かを判断する前に、次の注意が必要です。

  • クエリ インターリーブは、インポート モデルにのみ適用されます。 DirectQuery モデルには影響を与え "されません"。
  • クエリ インターリーブでは、VertiPaq ストレージ エンジン クエリによって消費される CPU のみを考慮します。 数式エンジンの操作には適用されません。
  • 単一の DAX クエリでは、複数の VertiPaq ストレージ エンジン クエリが発生する可能性があります。 DAX クエリは、ストレージエンジンクエリによって消費される CPU に基づいて、高速または低速と見なされます。 DAX クエリは測定単位です。
  • 更新操作は、既定でクエリインターリーブから保護されます。 実行時間の長い更新操作は、実行時間の長いクエリとは異なる方法で分類されます。

クエリインターリーブを有効にする

クエリインターリーブを有効にするには 、SchedulingBehavior プロパティを設定 します。 このプロパティは、次の値で指定できます。

説明
-1 自動。 エンジンによってキューの種類が選択されます。
0 (既定値) 先入れ先出し (FIFO)。
1 短いクエリ バイアス。 エンジンは、高速クエリを支持する圧力が高い場合に、実行時間の長いクエリを徐々に調整します。

現時点では、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 コアを予約し、処理操作の実行中に高速クエリに 4 を残し、CPU を消費します。 以下の 「Decayed queries」 セクションで説明したように、残りの 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 は、圧力の下での上限です。どの時点でもコア数が保証されるという保証はありません。

関連項目

Analysis Services のサーバーのプロパティ