方法: Fabric Data Warehouse使用率の傾向を観察する

適用されます:✅ Microsoft Fabric の SQL Analytics エンドポイントおよびデータ ウェアハウス

Microsoft Fabric容量メトリック アプリを使用して、Microsoft Fabricでデータ ウェアハウス ワークロードの傾向とスパイクを観察する方法について説明します。

Microsoft Fabric容量メトリック アプリは、すべてのFabricワークロードの容量使用量を 1 か所で可視化します。 これは、購入した容量と比較して、ワークロードのパフォーマンスとその使用状況を監視するために主に容量の管理者によって使用されます。

前提条件

Fabric容量内のすべての項目の全体的な傾向を観察する

Fabric容量メトリック アプリで、Multi メトリック リボン グラフを使用して、CU 使用率のピークを見つけます。 ピーク時のエンドユーザー アクティビティ、夜間処理、定期的なレポートなどに一致するFabricの使用状況のパターンを探します。ピーク使用率や営業時間で最も多くの CU を消費しているリソースを特定します。

このグラフは、過去 14 日間の高レベルの CU 傾向を提供して、どのFabricワークロードが最も多くの CU を使用したかを確認できます。

  1. 項目テーブルを使用して、ほとんどのコンピューティングを消費している特定のウェアハウスを識別します。 複数メトリック リボン グラフの Items テーブルには、項目レベルでの消費量の集計が表示されます。 たとえば、このビューでは、最も多くの CU を消費した項目を特定できます。
  2. [Select item kind(s)] (項目の種類の選択) ドロップダウン リストで [Warehouse] (ウェアハウス) を選択します。
  3. [項目] テーブルを [CU] の降順で並べ替えます。
  4. 最も多い容量ユニット、アクティビティの全体的な期間、ユーザー数などを使って、項目を特定できるようになります。

ピークアクティビティを徹底的に分析する

タイムポイント グラフを使用して、CU 使用率がピークであったアクティビティの範囲を特定します。 使用率を占める個々の対話型アクティビティとバックグラウンド アクティビティを識別できます。

次のアニメーション画像は、使用率、スロットリング、超過分の情報を詳しく調べるための手順を示しています。 詳細については、「throttling in Microsoft Fabric」を参照してください。

ドリルスルーの手順を表示するメトリック アプリのアニメーション GIF。

  1. タイムポイント探索グラフの [使用率] タブを選んで、容量の使用率が購入量を超えたタイムポイントを特定します。 黄色の点線は、SKU の上限を示します。 容量で自動スケーリングが有効になっている場合、SKU の上限は、購入した SKU と自動スケーリングの有効化に基づきます。
  2. [調整] タブを選んで、[Background rejection] (バックグラウンドの拒否) セクションに移動します。これは、ウェアハウスの要求に最も適しています。 前のアニメーション画像の例では、2023 年 10 月 16 日午後 12 時 57 分に、容量内のすべてのバックグラウンド要求が調整されたことがわかります。 100% 行は、購入したFabric SKU に基づく上限を表します。
  3. [Overages] (超過分) タブを選びます。このグラフでは、一定期間にわたって回収および繰越される負債の概要がわかります。
    • 追加 % (緑): 容量が過負荷になり、負債バケットへの追加が開始されたとき。
    • バーンダウン % (青): 負債のバーンダウンが始まり、全体的な容量使用率が 100% を下回ったとき。
    • 累積 % (赤): タイムポイントでの負債全体の合計を表します。 これは最終的に削除する必要があります。
  4. [使用率]、[スロットリング]、または [Overages] (超過分) タブで特定のタイムポイントを選択し、さらに詳細に分析するための [詳細表示] ボタンを有効化します。
  5. [探索する] を選びます。 新しいページで、対話型とバックグラウンド両方の操作の詳細を調べるためのテーブルが提供されます。 このページには、24 時間のスムージング ロジックにより、その時点では発生していないいくつかのバックグラウンド操作が示されます。 前のアニメーション画像では、選んだタイムポイントでバックグラウンド操作がまだスムージングされているため、10 月 15 日午後 12:57 から 10 月 16 日午後 12:57 の間に操作が表示されます。
  6. [Background operations] (バックグラウンド操作) テーブルでは、ユーザー、操作、開始/停止日時、最も多くの CU を消費した期間もわかります。

    • また、操作のテーブルには InProgress である操作の一覧が用意されているため、実行時間の長いクエリとその現在の CU 消費量を理解できます。

    • 多くのリソースを消費した操作の識別: テーブルを 合計 CU(s) の降順で並べ替えて最も負荷の高いクエリを見つけた後に、操作 ID 使用して操作を一意に識別します。 これは、分散ステートメント ID であり、動的管理ビュー (DMV) や Query Insights などの他の監視ツールで、sys.dm_exec_requests 内の dist_statement_id や query insights.exec_requests_history 内の のように、エンドツーエンドの追跡可能性を確保するために使用できます。 例 :

      次のサンプル T-SQL クエリでは、のクエリ内でsys.dm_exec_requestsを使用します。

      SELECT * FROM sys.dm_exec_requests 
WHERE dist_statement_id = '00AA00AA-BB11-CC22-DD33-44EE44EE44EE';

      次の T-SQL クエリでは、 ビューでユーザーが開始したクエリのqueryinsights.exec_requests_history使用します。

      SELECT * FROM queryinsights.exec_requests_history 
WHERE distributed_statement_id = '00AA00AA-BB11-CC22-DD33-44EE44EE44EE`;
  7. Burndown テーブル グラフは、この容量で実行されているさまざまなFabric ワークロードと、選択したタイムポイントで消費される % コンピューティングを表します。
    • [DMS] のテーブル エントリは、自分のウェアハウス ワークロードです。 前のアニメーション画像の例では、DMS は全体的な繰越負債に 26% を追加しています。
    • [Cumulative %] (累積 %) 列では、容量が超過消費された割合が提供されます。 スロットリングを避けるには、この値が 100% を下回っている必要があります。 たとえば、前のアニメーション画像の例の 2433.84% は、DMS が現在の SKU (F2) で許可される容量の 24 倍を使ったことを示しています。

関連するコンテンツ

  • Last updated on