クエリ ストアによるパフォーマンスの監視
適用対象:
Azure Database for PostgreSQL - 単一サーバー
重要
Azure Database for PostgreSQL - シングル サーバーは廃止パスにあります。 Azure Database for PostgreSQL - フレキシブル サーバーにアップグレードすることを強くお勧めします。 Azure Database for PostgreSQL - フレキシブル サーバーへの移行の詳細については、Azure Database for PostgreSQL シングル サーバーの現状に関するページを参照してください。
Azure Database for PostgreSQL のクエリ ストア機能では、一定期間にわたってクエリ パフォーマンスを追跡する手段が提供されます。 クエリ ストアを使用すると、実行時間が最長のクエリおよびリソースを最も消費しているクエリを迅速に特定できるので、パフォーマンスのトラブルシューティングが簡単になります。 クエリ ストアでは、クエリおよびランタイム統計の履歴が自動的にキャプチャされて保持されるので、それらを確認できます。 データベースの使用パターンを確認できるように、データが時間枠で区切られます。 すべてのユーザー、データベース、クエリに関するデータが Azure Database for PostgreSQL インスタンス内の azure_sys という名前のデータベースに格納されます。
重要
azure_sys データベースまたはそのスキーマを変更しないでください。 そうすると、クエリ ストアおよび関連するパフォーマンス機能が正しく機能しません。
クエリ ストアの有効化
クエリ ストアはオプトイン機能なので、既定ではサーバー上でアクティブになりません。 ストアは特定のサーバー上のすべてのデータベースに対してグローバルで有効または無効になり、データベースごとにオンまたはオフにすることはできません。
Azure portal を使用してクエリ ストアを有効にする
- Azure portal にサインインし、ご利用の Azure Database for PostgreSQL サーバーを選択します。
- メニューの [設定] セクションで、 [サーバー パラメーター] を選択します。
pg_qs.query_capture_modeパラメーターを検索します。- 値を
TOPに設定して保存します。
クエリ ストアでの待機統計を有効にするには、次の手順に従います。
pgms_wait_sampling.query_capture_modeパラメーターを検索します。- 値を
ALLに設定して保存します。
または Azure CLI を使用して、これらのパラメーターを設定することもできます。
az postgres server configuration set --name pg_qs.query_capture_mode --resource-group myresourcegroup --server mydemoserver --value TOP
az postgres server configuration set --name pgms_wait_sampling.query_capture_mode --resource-group myresourcegroup --server mydemoserver --value ALL
azure_sys データベースに保持するデータの最初のバッチには、最大で 20 分ほどかかります。
クエリ ストア内の情報
クエリ ストアには、次の 2 つのストアがあります。
- クエリ実行の統計情報を保持するためのランタイム統計ストア。
- 待機統計情報を保持するための待機統計ストア。
クエリ ストアを使用するための一般的なシナリオは次のとおりです。
- 指定された時間枠内にクエリが実行された回数を確認する
- 大きなデルタを確認するために時間枠間でクエリの平均実行回数を比較する
- 過去 X 時間に実行時間が最も長かったクエリを識別する
- リソースを待機している上位 N 件のクエリを特定する
- 特定のクエリの待機の性質を理解する
領域の使用量を最小限に抑えるために、ランタイム統計ストア内のランタイム実行統計は、固定の構成可能な時間枠で集計されます。 これらのストア内の情報は、クエリ ストアのビューに対してクエリを実行することで表示できます。
クエリ ストア情報へのアクセス
クエリ ストア データは、Postgres サーバー上の azure_sys データベースに格納されます。
次のクエリでは、クエリ ストア内のクエリに関する情報が返されます。
SELECT * FROM query_store.qs_view;
また、次のクエリは待機統計に関するものです。
SELECT * FROM query_store.pgms_wait_sampling_view;
待機クエリの検索
待機イベントの種類では、類似性によってさまざまな待機イベントがバケットに結合されます。 クエリ ストアでは、待機イベントの種類、特定の待機イベント名、対象のクエリが提供されます。 この待機情報をクエリのランタイム統計に関連付けられることは、クエリのパフォーマンス特性に何が寄与しているかをより深く理解できることを意味します。
クエリ ストア内の待機統計を使用してワークロードの詳細な分析情報を得る方法の例を次にいくつか示します。
| 観測 | 操作 |
|---|---|
| ロック待機が長い | 影響を受けているクエリのクエリ テキストを確認し、ターゲット エンティティを識別します。 同じエンティティを変更する他のクエリのクエリ ストアで、頻繁に実行されているクエリ、実行時間が長いクエリ、あるいはその両方を探します。 これらのクエリを特定した後で、コンカレンシーを向上させるためにアプリケーション ロジックを変更するか、より制限の低い分離レベルを使用します。 |
| バッファー IO 待機が長い | クエリ ストア内で物理読み取り回数が多いクエリを検索します。 それらと IO 待機が長いクエリが一致する場合は、スキャンではなくシークを実行するために、基になるエンティティへのインデックスの導入を検討します。 これにより、クエリの IO オーバーヘッドが最小限に抑えられます。 ポータル上でサーバーの [パフォーマンスの推奨事項] を調べて、このサーバーに対してクエリを最適化するインデックスの推奨事項があるかどうかを確認します。 |
| メモリ待機が多い | クエリ ストア内で、メモリを最も消費しているクエリを探します。 おそらくこれらのクエリによって、影響を受けているクエリの進行がさらに遅れています。 ポータル上でサーバーの [パフォーマンスの推奨事項] を調べて、これらのクエリを最適化するインデックスの推奨事項があるかどうかを確認します。 |
構成オプション
クエリ ストアが有効になっている場合、データは 15 分間の集計ウィンドウで保存され、ウィンドウあたり最大 500 件の個別のクエリが保存されます。
次のオプションは、クエリ ストア パラメーターを構成するために使用できます。
| パラメーター | 説明 | [Default] | Range |
|---|---|---|---|
| pg_qs.query_capture_mode | 追跡対象のステートメントを設定します。 | なし | none、top、all |
| pg_qs.max_query_text_length | 保存できるクエリの最大長を設定します。 これより長いクエリは切り詰められます。 | 6000 | 100 - 10K |
| pg_qs.retention_period_in_days | 保有期間を設定します。 | 7 | 1 - 30 |
| pg_qs.track_utility | ユーティリティ コマンドを追跡するかどうかを設定します | on | on、off |
待機統計には次のオプションが適用されます。
| パラメーター | 説明 | [Default] | Range |
|---|---|---|---|
| pgms_wait_sampling.query_capture_mode | 待機統計の追跡対象のステートメントを設定します。 | なし | none、all |
| Pgms_wait_sampling.history_period | 待機イベントをサンプリングする頻度をミリ秒単位で設定します。 | 100 | 1-600000 |
Note
pg_qs.query_capture_mode は pgms_wait_sampling.query_capture_mode に優先します。 pg_qs.query_capture_mode が NONE の場合、pgms_wait_sampling.query_capture_mode の設定は効果がありません。
パラメーターに対して別の値を取得または設定するには Azure portal または Azure CLI を使用します。
ビューと関数
次のビューと関数を使用してクエリ ストアを表示および管理します。 PostgreSQL の public ロールに属するユーザーは、これらのビューを使用してクエリ ストア内のデータを表示できます。 これらのビューは、azure_sys データベース内でのみ使用できます。
クエリは、リテラルと定数を削除した後、その構造を調べることで正規化されます。 2 つのクエリがリテラル値を除いて同一の場合、それらは同じハッシュを持ちます。
query_store.qs_view
このビューでは、クエリ ストア内のクエリ テキスト データが返されます。 個別の query_text ごとに 1 つの行があります。 このデータは、ポータル、API、または CLI の [インテリジェント パフォーマンス] セクションを介して入手できませんが、azure_sys に接続し、'query_store.query_texts_view' に対してクエリを実行することによって検出できます。
| 名前 | Type | 参照 | 説明 |
|---|---|---|---|
| runtime_stats_entry_id | bigint | runtime_stats_entries テーブルからの ID | |
| user_id | oid | pg_authid.oid | ステートメントを実行したユーザーの OID |
| db_id | oid | pg_database.oid | ステートメントが実行されたデータベースの OID |
| query_id | bigint | ステートメントの解析ツリーから計算される内部ハッシュ コード | |
| query_sql_text | Varchar(10000) | 代表的なステートメントのテキスト。 同じ構造を持つ複数の異なるクエリがまとめてクラスター化されます。このテキストは、クラスター内の最初のクエリのテキストです。 | |
| plan_id | bigint | まだ使用できない、このクエリに対応するプランの ID | |
| start_time | timestamp | クエリは、タイム バケットによって集計されます｡バケットの期間は既定で 15 分です。 これは、このエントリのタイム バケットに対応する開始時刻です。 | |
| end_time | timestamp | このエントリのタイム バケットに対応する終了時刻。 | |
| calls | bigint | クエリの実行回数 | |
| total_time | double precision | クエリの合計実行時間 (ミリ秒) | |
| min_time | double precision | クエリの最小実行時間 (ミリ秒) | |
| max_time | double precision | クエリの最大実行時間 (ミリ秒) | |
| mean_time | double precision | クエリの平均実行時間 (ミリ秒) | |
| stddev_time | double precision | クエリ実行時間の標準偏差 (ミリ秒) | |
| rows | bigint | ステートメントによって取得または影響された行の合計数 | |
| shared_blks_hit | bigint | ステートメントによる共有ブロック キャッシュ ヒットの合計数 | |
| shared_blks_read | bigint | ステートメントによって読み取られた共有ブロックの合計数 | |
| shared_blks_dirtied | bigint | ステートメントによって使用された共有ブロックの合計数 | |
| shared_blks_written | bigint | ステートメントによって書き込まれた共有ブロックの合計数 | |
| local_blks_hit | bigint | ステートメントによるローカル ブロック キャッシュ ヒットの合計数 | |
| local_blks_read | bigint | ステートメントによって読み取られたローカル ブロックの合計数 | |
| local_blks_dirtied | bigint | ステートメンによって使用されたローカル ブロックの合計数 | |
| local_blks_written | bigint | ステートメントによって書き込まれたローカル ブロックの合計数 | |
| temp_blks_read | bigint | ステートメントによって読み取られた一時ブロックの合計数 | |
| temp_blks_written | bigint | ステートメントによって書き込まれた一時ブロックの合計数 | |
| blk_read_time | double precision | ステートメントによってブロックの読み取りに費やされた時間の合計 (ミリ秒単位) (track_io_timing が有効になっている場合。それ以外の場合は 0) | |
| blk_write_time | double precision | ステートメントによってブロックの書き込みに費やされた時間の合計 (ミリ秒単位) (track_io_timing が有効になっている場合。それ以外の場合は 0) |
query_store.query_texts_view
このビューでは、クエリ ストア内のクエリ テキスト データが返されます。 個別の query_text ごとに 1 つの行があります。
| 名前 | Type | 説明 |
|---|---|---|
| query_text_id | bigint | query_texts テーブルの ID |
| query_sql_text | Varchar(10000) | 代表的なステートメントのテキスト。 同じ構造を持つ複数の異なるクエリがまとめてクラスター化されます。このテキストは、クラスター内の最初のクエリのテキストです。 |
query_store.pgms_wait_sampling_view
このビューでは、クエリ ストア内のクエリ テキスト データが返されます。 個別の query_text ごとに 1 つの行があります。 このデータは、ポータル、API、または CLI の [インテリジェント パフォーマンス] セクションを介して入手できませんが、azure_sys に接続し、'query_store.query_texts_view' に対してクエリを実行することによって検出できます。
| 名前 | Type | 参照 | 説明 |
|---|---|---|---|
| user_id | oid | pg_authid.oid | ステートメントを実行したユーザーの OID |
| db_id | oid | pg_database.oid | ステートメントが実行されたデータベースの OID |
| query_id | bigint | ステートメントの解析ツリーから計算される内部ハッシュ コード | |
| event_type | text | バックエンドによって待機されているイベントの種類 | |
| イベント | text | バックエンドによって現在待機されている場合に、待機イベントの名前 | |
| calls | Integer | 同じイベントがキャプチャされた回数 |
関数
Query_store.qs_reset() returns void
qs_reset では、クエリ ストアによってこれまでに収集されたすべての統計が破棄されます。 この関数は、サーバー管理者ロールによってのみ実行できます。
Query_store.staging_data_reset() returns void
staging_data_reset では、クエリ ストアによってメモリ内で収集されたすべての統計 (つまり、データベースにまだフラッシュされていないメモリ内のデータ) が破棄されます。 この関数は、サーバー管理者ロールによってのみ実行できます。
Azure Monitor
Azure Database for PostgreSQL は、Azure Monitor の診断設定に統合されています。 診断設定を使用すると、ご自分の Postgres ログを、分析とアラート用の Azure Monitor ログ、ストリーミング用の Event Hubs、アーカイブ用の Azure Storage に JSON 形式で送信できます。
重要
この診断機能は、General Purpose 価格レベルとメモリ最適化価格レベルにのみあります。
診断設定を構成する
お使いの Postgres サーバーの診断設定を有効にするには、Azure portal、CLI、REST API、PowerShell を使用します。 構成するログ カテゴリは QueryStoreRuntimeStatistics と QueryStoreWaitStatistics です。
Azure portal を使用してリソース ログを有効にするには
- ポータルで、お使いの Postgres サーバーのナビゲーション メニューから [診断設定] に移動します。
- [診断設定を追加する] を選択します。
- この設定に名前を付けます。
- 任意の優先エンドポイント (ストレージ アカウント、イベント ハブ、ログ分析) を選択します。
- ログの種類として QueryStoreRuntimeStatistics と QueryStoreWaitStatistics を選択します。
- 設定を保存します。
この設定を、PowerShell、CLI、または REST API を使用して有効にするには、診断の設定に関する記事をご覧ください。
JSON ログの形式
次の表では、2 つのログの種類のフィールドについて説明します。 選択した出力エンドポイントに応じて、含まれるフィールドとそれらが表示される順序が異なることがあります。
QueryStoreRuntimeStatistics
| フィールド | 説明 |
|---|---|
| TimeGenerated [UTC] | ログが記録されたときのタイムスタンプ (UTC) |
| ResourceId | Postgres サーバーの Azure リソース URI |
| カテゴリ | QueryStoreRuntimeStatistics |
| OperationName | QueryStoreRuntimeStatisticsEvent |
| LogicalServerName_s | Postgres サーバー名 |
| runtime_stats_entry_id_s | runtime_stats_entries テーブルからの ID |
| user_id_s | ステートメントを実行したユーザーの OID |
| db_id_s | ステートメントが実行されたデータベースの OID |
| query_id_s | ステートメントの解析ツリーから計算される内部ハッシュ コード |
| end_time_s | このエントリのタイム バケットに対応する終了時刻 |
| calls_s | クエリの実行回数 |
| total_time_s | クエリの合計実行時間 (ミリ秒) |
| min_time_s | クエリの最小実行時間 (ミリ秒) |
| max_time_s | クエリの最大実行時間 (ミリ秒) |
| mean_time_s | クエリの平均実行時間 (ミリ秒) |
| ResourceGroup | リソース グループ |
| SubscriptionId | サブスクリプション ID |
| ResourceProvider | Microsoft.DBForPostgreSQL |
| リソース | Postgres サーバー名 |
| ResourceType | Servers |
QueryStoreWaitStatistics
| フィールド | 説明 |
|---|---|
| TimeGenerated [UTC] | ログが記録されたときのタイムスタンプ (UTC) |
| ResourceId | Postgres サーバーの Azure リソース URI |
| カテゴリ | QueryStoreWaitStatistics |
| OperationName | QueryStoreWaitEvent |
| user_id_s | ステートメントを実行したユーザーの OID |
| db_id_s | ステートメントが実行されたデータベースの OID |
| query_id_s | クエリの内部ハッシュ コード |
| calls_s | 同じイベントがキャプチャされた回数 |
| event_type_s | バックエンドによって待機されているイベントの種類 |
| event_s | バックエンドによって現在待機されている場合に、待機イベントの名前 |
| start_time_t | イベントの開始時刻 |
| end_time_s | イベントの終了時刻 |
| LogicalServerName_s | Postgres サーバー名 |
| ResourceGroup | リソース グループ |
| SubscriptionId | サブスクリプション ID |
| ResourceProvider | Microsoft.DBForPostgreSQL |
| リソース | Postgres サーバー名 |
| ResourceType | Servers |
制限事項と既知の問題
- PostgreSQL サーバーのパラメーター default_transaction_read_only がオンの場合、クエリ ストアはデータをキャプチャできません。
- 時間がかかる Unicode クエリ (>= 6000 バイト) が発生した場合は、クエリ ストア機能の実行が中断されることがあります。
- 読み取りレプリカには、プライマリ サーバーからクエリ ストア データがレプリケートされます。 つまり、読み取りレプリカのクエリ ストアでは、読み取りレプリカで実行されるクエリに関する統計情報は提供されません。
次のステップ
- 詳細については、クエリ ストアが特に役に立つシナリオに関するページをご覧ください。
- 詳細については、クエリ ストアの使用のベスト プラクティスに関するページをご覧ください。