アダプティブ キャッシュを監視する方法

この記事では、ワークロードが専用 SQL プールのアダプティブ キャッシュを最適に活用しているかどうかを判断して、低速なクエリ パフォーマンスを監視およびトラブルシューティングする方法について説明します。

専用 SQL プール ストレージ アーキテクチャでは、NVMe ベースの SSD に存在するキャッシュ内で、最も頻繁に照会される列ストア セグメントが自動的に階層化されます。 キャッシュに存在するセグメントをクエリが取得すると、パフォーマンスが向上します。

Azure Portal を使用したトラブルシューティング

Azure Monitor を使用してキャッシュ メトリックを表示し、クエリのパフォーマンスをトラブルシューティングできます。 まず Azure portal に移動し、[ 監視]、[ メトリック] の順にクリックし、 スコープを選択します。

検索バーとドロップダウン バーを使用して、専用 SQL プールを見つけます。 次に、[適用] を選択します。

キャッシュのトラブルシューティングの主要なメトリックは、 キャッシュ ヒット率 と キャッシュ使用率です。 [ キャッシュ ヒット率 ] を選択し、[ メトリックの追加 ] ボタンを使用して キャッシュの使用率を追加します。

キャッシュ ヒット率と使用率

次のマトリックスでは、キャッシュ メトリックの値に基づくシナリオについて説明します。

	キャッシュヒット率が高い	キャッシュヒット率が低い
キャッシュ使用率が高い	シナリオ 1	シナリオ 2
キャッシュ使用率が低い	シナリオ 3	シナリオ 4

シナリオ 1: キャッシュを最適に使用しています。 クエリの速度が低下する可能性があるその他の領域のトラブルシューティングを行います。

シナリオ 2: 現在の作業データ セットがキャッシュに収まらないため、物理読み取りによるキャッシュ ヒット率が低くなります。 パフォーマンス レベルをスケールアップし、ワークロードを再実行してキャッシュを埋めることを検討してください。

シナリオ 3: キャッシュに関係のない理由により、クエリの実行速度が低下している可能性があります。 クエリの速度が低下する可能性があるその他の領域のトラブルシューティングを行います。 コストを節約するために、 インスタンスをスケールダウン してキャッシュ サイズを減らすことも検討できます。

シナリオ 4: コールド キャッシュが存在していたため、クエリが遅かった原因である可能性があります。 作業データセットがキャッシュされるようになったので、クエリを再実行することを検討してください。

重要

ワークロードの再実行後にキャッシュ ヒット率またはキャッシュ使用率が更新されない場合は、ワーキング セットが既にメモリ内に存在している可能性があります。 クラスター化列ストア テーブルのみがキャッシュされます。

次のステップ

一般的なクエリ パフォーマンスチューニングの詳細については、「 クエリ実行の監視」を参照してください。