最終更新日 2024年04月01日(月)

Postgres のデータキャッシングは、事前に割り当てられたり保証されたりしません。むしろ、これは見積に過ぎず、ワークロードに応じて大きく異なります。Heroku Postgres プランには、特定の量のシステム RAM​ が含まれています。その多くはキャッシングに使用されますが、ユーザーが確認できるデータベースでのキャッシングもそれとあまり変わりません。適切に設計されたアプリケーションは、キャッシュからのクエリの 99% 以上を処理します。この記事では、Postgres でキャッシングする方法の概要を示します。

PostgreSQL でのデータキャッシングの方法

Postgres には、キャッシングのメモリ割り当てに直接影響する設定がいくつかありますが、Postgres が使用するほとんどのキャッシュは、基礎となるオペレーティングシステムによって提供されます。Postgres は、他のほとんどのデータベースシステムとは異なり、多くの操作のためにオペレーティングシステムのページキャッシュを積極的に使用します。

例として、サーバーを合計 7.5 GB のシステムメモリでプロビジョニングするとします。この 7.5 GB のうち、ごく一部がオペレーティングシステムのカーネルによって使用され、さらに少量のシステムメモリが Postgres などの他のプログラムに使用されます。残り (システムメモリの 80 ～ 95%) は、オペレーティングシステムによるデータのキャッシングに使用されます。

Heroku Postgres インスタンスのオペレーティングシステムと他の実行中のプログラムのメモリフットプリントは平均 500 MB であることがわかりました。コストはプランのサイズに関係なくほぼ固定されています。Postgres がこの大量のメモリを割り当てる方法はいくつかありますが、通常、メモリの大部分は管理がオペレーティングシステムに任されています。

共有バッファキャッシュ

Postgres は、自身が割り当て、データやインデックスをメモリ内に保持するために内部的に使用する “共有バッファキャッシュ” を管理しています。この割り当ては、専用の Postgres インスタンス (すべての Heroku Postgres インスタンスなど) を実行しているサーバーの合計システムメモリの約 15 ～ 25% になるように設定されています。残りの使用可能なメモリは、Postgres によって 2 つの目的 (データやインデックスをオペレーティングシステムのページキャッシュを使用してディスク上にキャッシュするためと、内部操作やデータ構造のため) に使用されます。

共有バッファキャッシュの割り当ては、データベースプラン​によって異なります。

データベースの shared_buffers​ 値を確認するには、pg:psql​ セッション​を開いて次を実行します。

SHOW shared_buffers;

インメモリキャッシュ

最近ディスクとの間で読み書きされたデータは、オペレーティングシステムのページキャッシュを通過するため、メモリ内にキャッシュされています。その間、読み取りはキャッシュから処理されるため、ブロックデバイス I/O 操作が削減され、その結果としてスループットが向上します。ただし、このメモリも使用する Postgres 操作がいくつかあり、キャッシュが無効になります。

最も注目すべきは、内部のメモリ内クイックソートやハッシュテーブル、GROUP BY 操作など、クエリを実行するために行われる特定の種類の内部操作です。

work_mem

work_mem​ という Postgres 設定によって指定された特定の量のメモリをクエリ内のすべての結合で使用できます。PostgreSQL の work_mem​ 設定は、一時ディスクファイルに書き込む前に、ソートテーブルやハッシュテーブルなどのクエリ操作で使用される基本の最大メモリ量を設定します。

これらの各操作では、通常であればデータやインデックスのキャッシングに使用されるメモリが使用される可能性があります。ただし、これらの操作は、その処理のために同じ情報をディスクから読み取らなくても済むという意味で、キャッシングの 1 つの形態でもあります。

work_mem​ のデフォルト設定はデータベースプラン​によって異なります。

データベースの work_mem​ 値を確認するには、pg:psql​ セッション​を開いて次を実行します。

SHOW work_mem;

カスタムの work_mem​ 値は次のように設定できます。

• 取引ごと: ​SET LOCAL work_mem = '100 MB';
• セッションごと: ​SET work_mem = '100 MB';
• ロールごと: ​ALTER ROLE username SET work_mem = '100 MB';
• データベースレベル: ​ALTER DATABASE database_name SET work_mem = '100 MB';

work_mem​ 設定をロールごとまたはデータベースレベルで変更すると、変更は新しい接続にのみ適用されます。

VACUUM と DDL

すべての DDL 操作と同様に、ユーザー自身による VACUUM​ の実行や autovacuum デーモンの使用など、メモリを必要とする他の操作があります。DDL の場合、インデックスの作成には大量のメモリが消費される傾向があり、データとインデックスのキャッシュに使用可能なメモリも一時的に消費されます。

Heroku Postgres プラン​は、主に使用可能なシステム RAM の量によって異なります。ワークロードにとってどのようなプランが最適かを理解するための最善の方法は、実際に試してみることです。

コールドキャッシュが存在することの意味

何らかの理由で、本番プランの Heroku Postgres データベースでサービスの中断が発生した場合、データベースがオンラインに戻ったときに “コールドキャッシュ” があるというメッセージを受け取ることがあります。このメッセージが表示された場合は、基礎となるハードウェアが影響を受けており、その結果、データベースはデータがキャッシュされていない新しいホストでオンラインに戻ります。新しい Postgres インスタンスでのコールドキャッシュの問題を軽減するには、このナレッジベースの記事​を参照してください。

フォロワー​がある場合は、このメッセージが表示されたときに、データベースが新しいホストで使用可能になるのを待つのではなく、そのフォロワーをプロモートできます。