Snowflake Postgresのインサイト¶

キャッシュヒット¶

Postgresは通常、最も頻繁にアクセスするデータを共有バッファーキャッシュに保持しようとします。キャッシュヒット率は、受信したリクエスト数と比較して、バッファーキャッシュが処理できるコンテンツリクエスト数を測定します。キャッシュヒットは正常に処理されたリクエストであり、ミスとはそうでないリクエストです。ミスの場合、キャッシュを超えてファイルシステムに移動し、リクエストを実行します。

したがって、キャッシュヒットが100回、ミスが2回の場合、キャッシュヒット率は100/102であり、98%になります。

Postgresの通常の操作とパフォーマンスでは、Postgresのキャッシュヒット率を約99%にする必要があります。

キャッシュヒット率がこれを下回る場合は、より大きなメモリを持つインスタンスへの移動を検討する必要があります。

インデックスヒット¶

データベースにインデックスを追加することは、クエリとアプリケーションのパフォーマンスに不可欠です。インデックスは、大きなテーブルで特に価値があります。

インデックスヒット率は、実行されたクエリの総数に対する、インデックスを正常に利用したクエリまたはクエリ実行の合計数の比率またはパーセンテージとして測定されます。インデックスヒット率が高いほど、インデックスの利用率とクエリ全体のパフォーマンスが向上することを示しています。

一般的に、10,000行を超えるテーブルでは99%以上が求められます。10,000行を超えるテーブルで、インデックスの使用率がないか少ない場合は、インデックスの追加を始めるのに最適なタイミングです。

未使用インデックス¶

PostgreSQL での未使用のインデックスとは、テーブル上に作成されているが、アクティブに使用されていないインデックスを指します。これらのインデックスはディスク容量を消費し、メンテナンスが必要となり、パフォーマンスに悪影響を与える可能性があります。

Postgresで未使用のインデックスに注意する必要がある理由は次のとおりです。

• ストレージとディスク容量:未使用のインデックスは、他の目的でより有効活用できるディスク容量を占有します。その結果、ストレージコストが増加し、他のデータベースオブジェクトに使用できるスペースが減少する可能性があります。

• パフォーマンスへの影響:インデックスは、挿入、更新、削除などのデータ変更操作中にオーバーヘッドを発生させます。未使用のインデックスが多くある場合、データベースはテーブルに加えて複数のインデックスを更新する必要があるため、これらの操作に時間がかかります。

• クエリ実行速度の低下:Postgresのクエリオプティマイザーは、クエリの実行プランを生成するときに、利用可能なすべてのインデックスを考慮します。未使用のインデックスがある場合、オプティマイザーはこれらのインデックスの考慮に追加の時間を費やす可能性があり、その結果、クエリプランが最適化されず、クエリの実行速度が低下します。

• メンテナンスオーバーヘッド:インデックスを維持するには、 CPU やディスクI/Oなどのリソースが必要です。未使用のインデックスが多数ある場合、これらのリソースは不要なインデックスのメンテナンスタスクに浪費されます。

肥大化¶

肥大化とは、データベース内の不要な行や使用されていない行が蓄積され、ディスク容量が消費され、パフォーマンスが低下することを指します。主に、トランザクションワークロードが高いデータベースに影響します。Postgresの MVCC システムは、同時トランザクションを処理するために行の複数のバージョンを作成します。行が更新または削除されると、新しいバージョンが作成され、古いバージョンは不要としてマークされます。これらの不要な行は、トランザクションの整合性を維持し、同時操作中のデータの一貫性を確保するために、テーブルからすぐに削除されません。

不要な行が占有するディスク容量を解放するために、Postgresは定期的にバキューム処理を実行します。このプロセスは、テーブルから不要な行を特定して削除し、ディスク容量を解放して再利用できるようにします。肥大化は、大量のトランザクションによってバキューム処理の間に大量の不要な行が生成される場合に発生します。

テーブルまたはインデックスの合計サイズと比較して、不要な行が占有しているスペースの量を示すために肥大化の割合を表示します。表示される肥大化は推定または近似値です。テーブルの肥大化に関する詳細なデータが必要な場合は、拡張機能 pgstattuple を使用できます。ただし、これはリソースを集中的に使用する操作になる可能性があります。

低い肥大化:50%未満の肥大化は一般的に許容範囲と見なされ、通常、アクションは必要ありません。さらなる成長のために肥大化を監視し、バキュームの構成と設定を確認することをお勧めします。

高い肥大化:50%を超える肥大化は、パフォーマンスとディスク容量の使用率に大きな影響を与える可能性のある、高いレベルの肥大化を示しています。クエリの速度が遅い場合やパフォーマンスに問題がある場合は、手動でバキューム操作を実行したり、バキューム設定を変更したりするなどのアクションを検討する必要があります。

1GB 未満のテーブル、または肥大化率が10%未満のテーブルについては肥大化率は表示されません。

外れ値クエリ¶

これらは、実行時間の割合が最も高いクエリです。これには、非常に遅いが比較的頻度の低いクエリ、およびわずかに遅いが非常に一般的なクエリが含まれる場合があります。実行時間の割合が最も高いクエリは、アプリケーションレベルでのデータベースクエリのチューニングやインデックス作成の最適な開始点です。

長時間実行クエリ¶

PostgreSQL での長時間実行クエリは、データベースとアプリケーションにいくつかの悪影響を与える可能性があります。長時間実行クエリが一般的に望ましくないと見なされる理由は次のとおりです。

• パフォーマンスへの影響:長時間実行クエリは、 CPU 、メモリ、およびディスクI/Oなどのデータベースリソースを長時間拘束します。

• 競合の増加:長時間実行クエリは、ロックやデータベースオブジェクトへの同時アクセスなどの共有リソースの競合を増加させる可能性があります。

• スループットの低下:クエリの完了に時間がかかる場合は、特定の時間枠内に実行できるクエリの数が制限される可能性があります。

• ユーザーエクスペリエンスの低下:アプリケーションがタイムリーなクエリ実行に依存している場合、長時間実行クエリはユーザーエクスペリエンスに悪影響を与える可能性があります。ユーザーは遅延や不応答を経験する可能性があり、アプリケーションに対する不満やフラストレーションにつながります。

• リソースの枯渇:長時間実行クエリは過剰なメモリを消費する可能性があり、メモリ使用量が増加し、メモリ不足エラーが発生する可能性があります。また、ディスク上に大きな仮ファイルを生成する可能性があり、ディスク容量の問題を引き起こす可能性があります。

バキューム¶

インサイトパネルには、バキュームの統計も含まれています。テーブル名、前回のバキューム、前回の自動バキュームを確認できます。また、不要な行の数や、バキュームが最後に不要な行をクリーンアップした日時などのインサイトを得ることもできます。

バキュームの統計には次が含まれます。

• テーブル名

• 前回のバキューム: 最後に手動のバキューム操作が実行された日時

• 前回の自動バキューム: 最後に自動バキュームが実行された日時

• 行数: テーブルの合計行数

• 不要な行数: 現在テーブル内にある、バキューム処理されていないまたは不要な行の数

• スケール係数: 自動バキューム設定で設定されている現在のスケール係数

• しきい値: スケール係数を使用した、バキューム操作を必要とする行の総数

• バキューム処理が必要: テーブルを手動でバキューム処理する必要がある場合

テーブルのサイズ¶

Postgresテーブルのサイズに関する詳細は、インスタンスインサイトのテーブルサイズの下にあります。これは次のようなテーブル情報を表示します。

• テーブル名

• おおよその行数

• テーブルの合計サイズ

• テーブル上のインデックスのサイズ

• TOAST テーブル内のテーブルバイト数

• 生の行テーブルのサイズ

接続¶

接続インサイトには、データベースインスタンス内のすべての現在アクティブな接続とアイドル状態の接続が表示されます。アクティブな接続は、現在データベースに接続されており、クエリを実行中か、クエリの実行を待機しているセッションにあります。

アイドル状態の接続は一般的であり、本質的には問題ではありませんが、ワークロードと構成によっては問題になる可能性があります。アイドル状態の接続はメモリを消費するため、その数が多いとメモリ使用量が過剰になる可能性があります。アイドル状態の接続の数が多いことは、通常、データベースが接続プーリングの恩恵を受けることを示しています。

実行中の各セッションには、プロセスIDである pid があります。これはアクティブなバックエンド接続ごとに割り当てられた一意の識別子です。

接続、クエリ、または処理をキャンセルし、セッションを開いたままにするには、次のステートメントを使用します。

SELECT pg_cancel_backend(<pid>);

接続を閉じてトランザクションをロールバックする、より強制的なアクションは次のとおりです。

SELECT pg_terminate_backend(<pid>);