Aurora PostgreSQL チューニングの基本概念

Aurora PostgreSQL データベースをチューニングする前に、待機イベントは何か、そしてなぜ発生するのかを確認してください。Aurora PostgreSQL のベーシックメモリとディスクアーキテクチャも確認します。役立つアーキテクチャの図表については、PostgreSQLウィキブックを参照してください。

Aurora PostgreSQL の待機イベント

待機イベントは、セッションが待っているリソースを示します。例えば、待機イベントは Client:ClientReadAurora PostgreSQL がクライアントからのデータの受信を待っているときに発生します。セッションが待機する一般的なリソースには、次のようなものがあります。

例えば、クエリを満たすために、セッションで完全なテーブルスキャンを実行することがあります。データがまだメモリ上にない場合、セッションはディスク I/O が完了するまで待機します。バッファがメモリに読み込まれるときは、他のセッションが同じバッファにアクセスしているため、セッションは待機しなければならないことがあります。データベースは、事前定義された待機イベントを使用して待機を記録します。これらのイベントはカテゴリに分類されます。

待機イベント自体では、パフォーマンスの問題は表示されません。例えば、要求されたデータがメモリ上にない場合は、ディスクからデータを読み出す必要があります。あるセッションが更新のために行をロックすると、別のセッションはその行を更新できるようにロック解除されるまで待機します。コミットは、ログファイルへの書き込みが完了するまで待機する必要があります。待機は、データベースが正常に機能するために不可欠です。

一般的に、大量の待機イベントはパフォーマンスの問題を示します。そのような場合、待機イベントデータを使用して、セッションが時間を費やしている場所を特定できます。例えば、通常は分単位で実行されるレポートが数時間実行される場合、合計待機時間に最も多く寄与する待機イベントを特定できます。上位の待機イベントの原因を特定できる場合は、パフォーマンス向上のための変更を実行できることがあります。例えば、別のセッションによってロックされている行をセッションが待っている場合、ロックセッションを終了させることができます。

Aurora PostgreSQL メモリ

Aurora PostgreSQL メモリは、共有とローカルに分かれています。

Aurora PostgreSQL の共有メモリ

Aurora PostgreSQL は、インスタンスの起動時に共有メモリを割り当てます。共有メモリは複数のサブエリアに分割されています。以下では、その中でも特に重要なものについて説明します。

共有バッファ

共有バッファプールは、アプリケーション接続によって使用されている、または使用されていたすべてのページを保持する Aurora PostgreSQL メモリ領域です。ページは、ディスクブロックのメモリバージョンです。共有バッファプールは、ディスクから読み込まれたデータブロックをキャッシュします。プールは、ディスクからデータを再読み取りする必要性を減らし、データベースの運用効率を向上させます。

すべてのテーブルとインデックスは、固定サイズのページの配列として格納されます。各ブロックには、行に対応する複数のタプルが含まれています。タプルはどのページにも格納できます。

共有バッファプールには有限メモリがあります。新しいリクエストがメモリにないページを必要とし、メモリがもう存在しない場合、Aurora PostgreSQL は使用頻度の低いページを削除してリクエストに対応します。削除ポリシーは、クロックスイープアルゴリズムによって実装されます。

shared_buffersパラメータは、サーバーがデータをキャッシュするメモリ量を決定します。

ログ先行書き込み (WAL) バッファ

ログ先行書き込み (WAL) バッファは、Aurora PostgreSQL が後で永続的ストレージに書き込むトランザクションデータを保持します。WAL メカニズムを使用すると、Aurora PostgreSQL は次のことを実行できます。

クライアントがデータを変更すると、Aurora PostgreSQL は WAL バッファに変更内容を書き込みます。クライアントがCOMMITを発すると、WAL ライタプロセスはトランザクションデータを WAL ファイルに書き込みます。

wal_levelパラメータは、WAL に書き込まれる情報量を決定します。

Aurora PostgreSQL のローカルメモリ

すべてのバックエンドプロセスは、クエリ処理にローカルメモリを割り当てます。

ワークメモリ領域

ワークメモリ領域ソートとハッシュを実行するクエリのテンポラリデータを保持します。例えば、ORDER BY文節を持つクエリはソートを実行します。クエリは、ハッシュ結合と集約でハッシュテーブルを使用します。

テンポラリディスクファイルに書き込む前に、内部ソート操作とハッシュテーブルで使用するメモリ量を指定するwork_memパラメータです。デフォルト値は 4 MB です。複数のセッションを同時に実行でき、各セッションでメンテナンスオペレーションを並行して行うことができます。このため、使用されるワークメモリの合計は、work_mem設定の何倍にもなることがあります。

メンテナンス作業用メモリ領域

メンテナンス作業用メモリ領域は、メンテナンスオペレーション用のデータをキャッシュします。これらの操作には、バキューム処理、インデックス作成、外部キーの追加が含まれます。

maintenance_work_memパラメータは、メンテナンスオペレーションで使用されるメモリの最大量を指定します。デフォルト値は 64 MB です。データベースセッションでは、一度に 1 つのメンテナンスオペレーションしか実行できません。

テンポラリバッファ領域

テンポラリバッファ領域は、データベースセッションごとにテンポラリテーブルをキャッシュします。

各セッションは、指定した制限まで、必要に応じてテンポラリバッファを割り当てます。セッションが終了すると、サーバーはバッファをクリアします。

temp_buffersパラメータは、各セッションで使用されるテンポラリバッファの最大数を設定します。セッション内でテンポラリテーブルを初期に使用する前に、temp_buffers値を変更できます。

Aurora PostgreSQL プロセス

Aurora PostgreSQL は複数のプロセスを使用します。

Postmaster プロセス

Postmaster プロセスは、Aurora PostgreSQL を起動したときに初期のプロセスがスタートされます。Postmaster プロセスには、主に次のようなロールがあります。

バックエンドプロセス

Postmaster がクライアント要求を認証する場合、Postmaster は新しいバックエンドプロセスをフォークします。これは postgres プロセスとも呼ばれます。1 つのクライアントプロセスが 1 つのバックエンドプロセスに接続されます。クライアントプロセスとバックエンドプロセスは、Postmaster プロセスの介入なしに直接通信します。

バックグラウンドプロセス

Postmaster プロセスは、異なるバックエンドタスクを実行するいくつかのプロセスをフォークします。より重要なものとしては、以下のとおりです。