AnalyticDB:pg_buffercache

概要

AnalyticDB for PostgreSQLはpg_buffercache拡張機能を使用して、共有バッファーにキャッシュされたさまざまなページの観察可能なビューを提供します。 観測可能なビューを監視して、次の目的を達成できます。

• ホットスポットデータの特定 共有バッファーに頻繁に表示されるテーブルまたはインデックスは、システム内のアクセスホットスポットを表します。 テーブルまたはインデックスのクエリを最適化して、データベースのパフォーマンスを大幅に向上させることができます。

• キャッシュ設定の最適化 実際のキャッシュ使用量に基づいて共有バッファのサイズを調整して、重要なデータが完全にキャッシュされ、ディスクI/O操作を減らすことができます。

• パフォーマンスのボトルネックを防ぎます。 監視可能なビューを分析し、キャッシュリソースの追加やデータアクセスポリシーの調整などの予防措置を講じて、データベースの高いパフォーマンスを確保できます。

pg_prewarm拡張機能を使用して、将来頻繁にアクセスされる可能性のあるテーブルまたはインデックスを共有バッファーにプリロードできます。 これにより、データキャッシュミスによる最初のアクセスのレイテンシが大幅に削減され、システムが起動してアクセスモードの変更を予測するときに安定したデータベース応答が保証されます。

制限事項

AnalyticDB for PostgreSQLの次のインスタンスバージョンとマイナーバージョンは、pg_buffercache拡張機能をサポートしています。

• AnalyticDB for PostgreSQL V6.0 V6.6.2.5以降のインスタンス。

• AnalyticDB for PostgreSQL V7.0 V7.1.0.0以降のインスタンス。

• サーバーレスモードのAnalyticDB for PostgreSQLインスタンスは、pg_buffercache拡張機能をサポートしていません。

インストールとアンインストール

Install the extension

AnalyticDB for PostgreSQLインスタンスでpg_buffercache拡張機能を使用する前に、インスタンスの [拡張機能] ページで拡張機能をインストールする必要があります。 詳細については、「拡張機能のインストール、更新、およびアンインストール」をご参照ください。

拡張機能のアンインストール

AnalyticDB for PostgreSQLインスタンスでpg_buffercache拡張機能を使用する必要がなくなった場合は、インスタンスの [拡張機能] ページで拡張機能をアンインストールできます。 詳細については、「拡張機能のインストール、更新、およびアンインストール」をご参照ください。

例

コーディネーターノードのテーブルまたはインデックスのキャッシュ使用統計の照会

SELECT * FROM shared_buffer_stat_master_lockfree;

サンプル結果:

           relname         | percentage_in_shared_buffer | pages_in_shared_buffer
---------------------------+-----------------------------+------------------------
 others                    |                     0.53125 |                     85
 pg_depend_reference_index |                     0.09375 |                     15
 pg_depend                 |                     0.05625 |                      9
 ...

• relname: 共有バッファーのスペースを占有するテーブルまたはインデックスの名前。 このメトリックは、頻繁にアクセスされてキャッシュ効率とクエリのパフォーマンスに影響を与えるデータベースオブジェクトの分析に役立ちます。

• percentage_in_shared_buffer: テーブルまたはインデックスが占有する共有バッファの割合。 このメトリックは、共有バッファの大部分を占めるテーブルまたはインデックスを取得し、キャッシュ割り当てポリシーを変更するか、データアクセスモードを最適化してリソース使用量のバランスを取るかを決定するのに役立ちます。

• pages_in_shared_buffer: 共有バッファーにキャッシュされたテーブルまたはインデックスのページ数。 このメトリックは、データアクセスの局所性とキャッシュヒット率の評価に役立ちます。

計算ノードのテーブルまたはインデックスのキャッシュ使用統計の照会

SELECT * FROM shared_buffer_stat_segments_lockfree;

サンプル結果:

        relname         | percentage_in_shared_buffer
------------------------+-----------------------------
 gp_distribution_policy |                     0.00625
 pg_namespace_oid_index |                      0.0125
 pg_rewrite             |                     0.00625
...

計算ノードでのクエリ結果は、コーディネーターノードでのクエリ結果と同様です。 違いは、percentage_in_shared_bufferメトリックは、計算ノード間の各テーブルまたはインデックスによって占有される共有バッファの平均パーセンテージを示します。

コーディネーターノードの全体的なキャッシュ使用統計の

SELECT * FROM shared_buffer_summary_master_lockfree;

サンプル結果:

 pages_in_use | pages_marked_dirty | pages_total
--------------+--------------------+-------------
          594 |                594 |       16000

• pages_in_use: 共有バッファーで使用されているページの数。

• pages_marked_dirty: 共有バッファー内でdirtyとしてマークされたページの数。 ページは共有バッファーで変更されますが、ディスクに同期されません。 このメトリックは、書き込み操作のアクティビティと潜在的なI/Oライトバックワークロードを示します。

• pages_total: 共有バッファーで使用できるページの最大数。 このメトリックは、使用可能な合計キャッシュサイズを示します。

計算ノードの全体的なキャッシュ使用統計の照会

SELECT * FROM shared_buffer_summary_segments_lockfree;

サンプル結果:

 pages_in_use | pages_marked_dirty | pages_total
--------------+--------------------+-------------
        11328 |              11328 |       98304
...

計算ノードでのクエリ結果は、コーディネーターノードでのクエリ結果と同様です。 違いは、クエリ結果がすべての計算ノードの全体的な統計を示すことです。

テーブルまたはインデックスのキャッシュヒット統計の照会

構文

SELECT * FROM relation_shared_buffer_stat_lockfree('<Table name or index name>'::regclass);

例

SELECT * FROM relation_shared_buffer_stat_lockfree('adbpg_autoanalyze_test_table'::regclass);

サンプル結果:

           relname            | total_pages | pages_in_shared_buffer
------------------------------+-------------+------------------------
 adbpg_autoanalyze_test_table |       20055 |                   3327
(1 row)

• relname: テーブルまたはインデックスの名前。

• total_pages: データベース内のテーブルまたはインデックスの合計ページ数。

• pages_in_shared_buffer: 共有バッファーにキャッシュされたテーブルまたはインデックスのページ数。 total_pagesとpages_in_shared_bufferメトリックの値を比較して、キャッシュヒットの可能性と共有バッファの実際のキャッシュ効率を取得できます。 これにより、キャッシュ割り当てポリシーを変更するか、データアクセスモードを最適化してキャッシュの使用とクエリのパフォーマンスを向上させるかを決定できます。

テーブルのキャッシュヒット統計と関連するインデックスとTOASTテーブルの

構文

SELECT * FROM relation_detail_shared_buffer_stat_lockfree('<Table name or index name>'::regclass);

Parameters

• テーブルの名前を指定すると、テーブルのキャッシュヒット統計、テーブルインデックス、およびテーブルに依存するTOASTテーブルが返されます。

• インデックスの名前を指定すると、インデックスのキャッシュヒット統計のみが返されます。

例

SELECT * FROM relation_detail_shared_buffer_stat_lockfree('adbpg_autoanalyze_test_table'::regclass);

サンプル結果:

           relname            | total_pages | pages_in_shared_buffer
------------------------------+-------------+------------------------
 adbpg_autoanalyze_test_table |       20055 |                   3327
(1 row)

クエリを使用すると、指定されたテーブルと、共有バッファ内の関連インデックスまたはTOASTテーブルのキャッシュ統計を取得できます。 これにより、データベースのパフォーマンスを完全に分析および最適化できます。

この例では、adbpg_autoanalyze_test_tableテーブルの多数のページ (3327/20055) が共有バッファーにキャッシュされ、クエリの効率が向上します。 関連するadbpg_autoanalyze_test_table_i_idxインデックスのページがキャッシュされていない場合、インデックスを使用してクエリを実行するときに、高いパフォーマンスが得られない可能性があります。