次の方法で共有

リソース使用量/メモリ

autovacuum_work_mem

特性 価値
カテゴリ リソース使用量/メモリ
Description 各自動バキューム worker プロセスで使用される最大メモリを設定します。
データの種類 整数
既定値 -1
使用できる値 -1-2097151
パラメーターのタイプ dynamic
Documentation autovacuum_work_mem

コミットタイムスタンプバッファー

特性 価値
カテゴリ リソース使用量/メモリ
Description コミット タイムスタンプ キャッシュに使用される専用バッファー プールのサイズを設定します。 この値をshared_buffersの分数として決定するには、0 を指定します。
データの種類 整数
既定値 1024
使用できる値 0-131072
パラメーターのタイプ 静的
Documentation `commit_timestamp_buffers`

動的共有メモリータイプ

特性 価値
カテゴリ リソース使用量/メモリ
Description 使用されている動的共有メモリの実装を選択します。
データの種類 リスト
既定値 posix
使用できる値 posix
パラメーターのタイプ 読み取り専用
Documentation dynamic_shared_memory_type

hash_mem_multiplier

特性 価値
カテゴリ リソース使用量/メモリ
Description ハッシュ テーブルに使用する "work_mem" の倍数。
データの種類 numeric
既定値 2
使用できる値 1-1000
パラメーターのタイプ dynamic
Documentation hash_mem_multiplier

huge_pages

特性 価値
カテゴリ リソース使用量/メモリ
Description Linux または Windows での巨大なページの使用。
データの種類 リスト
既定値 try
使用できる値 on,off,try
パラメーターのタイプ 静的
Documentation 大きなページ

Description

巨大なページは、より大きなブロックでメモリを管理できる機能です。 通常、標準の 4 KB ページとは対照的に、最大 2 MB のブロックを管理できます。

巨大なページを使用すると、CPU を効果的にオフロードするパフォーマンス上の利点が得られます。

  • 変換ルックアサイド バッファー (TLB) ミスの減少など、メモリ管理タスクに関連するオーバーヘッドを削減します。
  • メモリ管理に必要な時間を短縮します。

具体的には、PostgreSQL では、共有メモリ領域にのみ巨大なページを使用できます。 共有バッファーには、共有メモリ領域の重要な部分が割り当てられます。

もう 1 つの利点は、巨大なページが共有メモリ領域をディスクにスワップするのを防ぎ、パフォーマンスをさらに安定させるということです。

推奨事項

  • 大量のメモリ リソースを持つサーバーの場合は、巨大なページを無効にしないでください。 巨大なページを無効にすると、パフォーマンスが低下する可能性があります。
  • 巨大なページをサポートしていない小規模なサーバーから始めて、そのサーバーにスケールアップする場合は、シームレスな移行と最適なパフォーマンスを得るために、 huge_pages 設定を TRY に維持します。

Azure 固有の注

4 つ以上の仮想コアを持つサーバーの場合、基になるオペレーティング システムから巨大なページが自動的に割り当てられます。 この機能は、仮想コアが 4 つ未満のサーバーでは使用できません。 shared_buffersの変更など、共有メモリの設定が変更されると、膨大なページの数が自動的に調整されます。

huge_page_size

特性 価値
カテゴリ リソース使用量/メモリ
Description 要求する必要がある巨大なページのサイズです。
データの種類 整数
既定値 0
使用できる値 0
パラメーターのタイプ 読み取り専用
Documentation huge_page_size

io_combine_limit

特性 価値
カテゴリ リソース使用量/メモリ
Description データの読み取りと書き込みのサイズに関する制限。
データの種類 整数
既定値 16
使用できる値 1-128
パラメーターのタイプ dynamic
Documentation io_combine_limit

io_max_combine_limit

特性 価値
カテゴリ リソース使用量/メモリ
Description サーバー全体でio_combine_limitを制限する設定。
データの種類 整数
既定値 16
使用できる値 1-128
パラメーターのタイプ dynamic
Documentation io_max_combine_limit

io_max_concurrency

特性 価値
カテゴリ リソース使用量/メモリ
Description 1 つのプロセスが同時に実行できる IO の最大数。
データの種類 整数
既定値 64
使用できる値 -1-1024
パラメーターのタイプ 静的
Documentation io_max_concurrency

io_method

特性 価値
カテゴリ リソース使用量/メモリ
Description 非同期 I/O を実行するメソッドを選択します。
データの種類 リスト
既定値 worker
使用できる値 worker,sync
パラメーターのタイプ 静的
Documentation io_method

I/Oワーカーズ

特性 価値
カテゴリ リソース使用量/メモリ
Description io_method=worker の IO ワーカー プロセスの数。
データの種類 整数
既定値 3
使用できる値 1-32
パラメーターのタイプ dynamic
Documentation io_workers

logical_decoding_work_mem

特性 価値
カテゴリ リソース使用量/メモリ
Description 論理デコードに使用する最大メモリを設定します。 この量のメモリは、ディスクにスピルする前に、各内部並べ替えバッファーで使用できます。
データの種類 整数
既定値 65536
使用できる値 64-2147483647
パラメーターのタイプ dynamic
Documentation logical_decoding_work_mem (論理デコーディングワークメモリ)

maintenance_work_mem

特性 価値
カテゴリ リソース使用量/メモリ
Description メンテナンス操作に使用する最大メモリを設定します。 これには、VACUUM や CREATE INDEX などの操作が含まれます。
データの種類 整数
既定値 サーバーに割り当てられているリソース (仮想コア、RAM、またはディスク領域) によって異なります。
使用できる値 1024-2097151
パラメーターのタイプ dynamic
Documentation maintenance_work_mem

Description

maintenance_work_mem は PostgreSQL の構成パラメーターです。 VACUUM、CREATE INDEX、ALTER TABLEなど、メンテナンス操作に割り当てられるメモリの量が制御されます。 クエリ操作のメモリ割り当てに影響する work_memとは異なり、 maintenance_work_mem はデータベース構造を維持および最適化するタスク用に予約されています。

![注] maintenance_work_mem を過度にアグレッシブな値に設定すると、システムのメモリ不足エラーが定期的に発生する可能性があります。 このパラメーターを変更する前に、サーバーで使用可能なメモリの量と、前に説明したタスクにメモリを割り当てることができる同時実行操作の数を理解することが非常に重要です。

重要なポイント

  • バキューム メモリ キャップ: maintenance_work_memを増やして消滅タプルのクリーンアップを高速化したい場合は、VACUUMには識別子収集に制限があるため、注意が必要です。 このプロセスでは、最大 1 GB のメモリのみを使用できます。
  • 自動バキュームのメモリの分離: autovacuum_work_mem 設定を使用して、自動バキューム操作が個別に使用するメモリを制御できます。 この設定は、 maintenance_work_memのサブセットとして機能します。 他のメンテナンス タスクやデータ定義操作のメモリ割り当てに影響を与えずに、自動バキュームが使用するメモリの量を決定できます。

Azure 固有の注

maintenance_work_mem サーバー パラメーターの既定値は、Azure Database for PostgreSQL フレキシブル サーバーのインスタンスをプロビジョニングするときに、そのコンピューティング用に選んだ製品名に基づいて計算されます。 その後、フレキシブル サーバーをサポートするコンピューティングに対する製品選択が変更された場合、そのインスタンスの maintenance_work_mem サーバー パラメーターの既定値に影響が及ぶことはありません。

インスタンスに割り当てられた製品を変更するたびに、次の数式の値に従って、 maintenance_work_mem パラメーターの値も調整する必要があります。

maintenance_work_mem の値の計算に使用される数式は (long)(82.5 * ln(memoryGiB) + 40) * 1024 です。

前の数式に基づき、プロビジョニングされたメモリ容量に応じてこのサーバー パラメーターに設定される値を次の表に示します。

メモリ サイズ maintenance_work_mem
2 GiB 99,328 KiB
4 GiB 157,696 KiB
8 GiB 216,064 KiB
16 GiB 274,432 KiB
32 GiB 332,800 KiB
48 GiB 367,616 KiB
64 GiB 392,192 KiB
80 GiB 410,624 KiB
128 GiB 450,560 KiB
160 GiB 468,992 KiB
192 GiB 484,352 KiB
256 GiB 508,928 KiB
384 GiB 542,720 KiB
432 GiB 552,960 KiB
672 GiB 590,848 KiB

max_prepared_transactions（最大準備済みトランザクション）

特性 価値
カテゴリ リソース使用量/メモリ
Description 同時に準備されたトランザクションの最大数を設定します。
データの種類 整数
既定値 0
使用できる値 0-262143
パラメーターのタイプ 静的
Documentation max_prepared_transactions

max_stack_depth (最大スタック深度)

特性 価値
カテゴリ リソース使用量/メモリ
Description スタックの最大深度を KB 単位で設定します。
データの種類 整数
既定値 2048
使用できる値 2048
パラメーターのタイプ 読み取り専用
Documentation max_stack_depth

min_dynamic_shared_memory

特性 価値
カテゴリ リソース使用量/メモリ
Description 起動時に予約された動的共有メモリの量です。
データの種類 整数
既定値 0
使用できる値 0
パラメーターのタイプ 読み取り専用
Documentation min_dynamic_shared_memory

multixact_member_buffers

特性 価値
カテゴリ リソース使用量/メモリ
Description MultiXact メンバー キャッシュに使用される専用バッファー プールのサイズを設定します。
データの種類 整数
既定値 32
使用できる値 16-131072
パラメーターのタイプ 静的
Documentation multixact_member_buffers

multixact_offset_buffers

特性 価値
カテゴリ リソース使用量/メモリ
Description MultiXact オフセット キャッシュに使用される専用バッファー プールのサイズを設定します。
データの種類 整数
既定値 16
使用できる値 16-131072
パラメーターのタイプ 静的
Documentation multixact_offset_buffers

notify_buffers

特性 価値
カテゴリ リソース使用量/メモリ
Description LISTEN/NOTIFY メッセージ キャッシュに使用される専用バッファー プールのサイズを設定します。
データの種類 整数
既定値 16
使用できる値 16-131072
パラメーターのタイプ 静的
Documentation notify_buffers

シリアライズ可能なバッファ

特性 価値
カテゴリ リソース使用量/メモリ
Description シリアル化可能なトランザクション キャッシュに使用される専用バッファー プールのサイズを設定します。
データの種類 整数
既定値 32
使用できる値 16-131072
パラメーターのタイプ 静的
Documentation シリアライズ可能バッファ

共有バッファー

特性 価値
カテゴリ リソース使用量/メモリ
Description サーバーによって使用される共有メモリ バッファーの数を設定します。
データの種類 整数
既定値 サーバーに割り当てられているリソース (仮想コア、RAM、またはディスク領域) によって異なります。
使用できる値 16-1073741823
パラメーターのタイプ 静的
Documentation shared_buffers

Description

shared_buffers構成パラメーターは、データをバッファリングするために PostgreSQL データベースに割り当てられるシステム メモリの量を決定します。 これは、すべてのデータベース プロセスからアクセスできる一元化されたメモリ プールとして機能します。

データが必要な場合、データベース プロセスは最初に共有バッファーをチェックします。 必要なデータが存在する場合は、すばやく取得され、より時間のかかるディスク読み取りをバイパスします。 共有バッファーは、データベース プロセスとディスク間の仲介役として機能し、必要な I/O 操作の数を効果的に減らします。

Azure 固有の注

shared_buffers サーバー パラメーターの既定値は、Azure Database for PostgreSQL フレキシブル サーバーのインスタンスをプロビジョニングするときに、そのコンピューティング用に選んだ製品名に基づいて計算されます。 フレキシブル サーバーをサポートするコンピューティングに対する製品選択の後続の変更は、そのインスタンスの shared_buffers サーバー パラメーターの既定値には影響しません。

インスタンスに割り当てられた製品を変更するたびに、次の数式の値に従って、 shared_buffers パラメーターの値も調整する必要があります。

最大 2 GiB のメモリを持つ仮想マシンの場合、 shared_buffers の値の計算に使用される数式は memoryGib * 16384。

2 GiB を超える仮想マシンの場合、 shared_buffers の値の計算に使用される数式は memoryGib * 32768。

前の数式に基づき、プロビジョニングされたメモリ容量に応じてこのサーバー パラメーターに設定される値を次の表に示します。

メモリ サイズ 共有バッファー
2 GiB 32768
4 GiB 131072
8 GiB 262144
16 GiB 524288
32 GiB 1048576
48 GiB 1572864
64 GiB 2097152
80 GiB 2621440
128 GiB 4194304
160 GiB 5242880
192 GiB 6291456
256 GiB 8388608
384 GiB 12582912
432 GiB 14155776
672 GiB 22020096

共有メモリタイプ

特性 価値
カテゴリ リソース使用量/メモリ
Description メイン共有メモリ領域に使用される共有メモリ実装を選択します。
データの種類 リスト
既定値 mmap
使用できる値 mmap
パラメーターのタイプ 読み取り専用
Documentation shared_memory_type

サブトランザクションバッファ

特性 価値
カテゴリ リソース使用量/メモリ
Description サブトランザクション キャッシュに使用される専用バッファー プールのサイズを設定します。 この値をshared_buffersの分数として決定するには、0 を指定します。
データの種類 整数
既定値 1024
使用できる値 0-131072
パラメーターのタイプ 静的
Documentation サブトランザクションバッファ

テンポラリーバッファー

特性 価値
カテゴリ リソース使用量/メモリ
Description 各セッションで使用される一時バッファーの最大数を設定します。
データの種類 整数
既定値 1024
使用できる値 100-1073741823
パラメーターのタイプ dynamic
Documentation temp_buffers

トランザクションバッファ

特性 価値
カテゴリ リソース使用量/メモリ
Description トランザクション状態キャッシュに使用される専用バッファー プールのサイズを設定します。 この値をshared_buffersの分数として決定するには、0 を指定します。
データの種類 整数
既定値 1024
使用できる値 0-131072
パラメーターのタイプ 静的
Documentation transaction_buffers

vacuum_buffer_usage_limit

特性 価値
カテゴリ リソース使用量/メモリ
Description VACUUM、ANALYZE、自動バキュームのバッファー プール サイズを設定します。
データの種類 整数
既定値 2048
使用できる値 0-16777216
パラメーターのタイプ dynamic
Documentation vacuum_buffer_usage_limit

作業メモリー

特性 価値
カテゴリ リソース使用量/メモリ
Description クエリ ワークスペースに使用する最大メモリを設定します。 この多くのメモリは、一時ディスク ファイルに切り替える前に、各内部並べ替え操作とハッシュ テーブルで使用できます。
データの種類 整数
既定値 4096
使用できる値 4096-2097151
パラメーターのタイプ dynamic
Documentation work_mem

Description

PostgreSQL の work_mem パラメーターは、各データベース セッションのプライベート メモリ領域内の特定の内部操作に割り当てられるメモリの量を制御します。 これらの操作の例として、並べ替えとハッシュがあります。

共有メモリ領域にある共有バッファーとは異なり、 work_mem はセッションごとまたはクエリごとのプライベート メモリ領域に割り当てられます。 適切な work_mem サイズを設定することで、これらの操作の効率を大幅に向上させ、一時データをディスクに書き込む必要性を減らすことができます。

重要なポイント

  • プライベート接続メモリ: work_mem は、各データベース セッションで使用されるプライベート メモリの一部です。 このメモリは、 shared_buffers が使用する共有メモリ領域とは異なります。
  • クエリ固有の使用方法: すべてのセッションまたはクエリで work_memが使用されるわけではありません。 SELECT 1のような単純なクエリでは、work_memが必要な可能性はほとんどありません。 ただし、並べ替えやハッシュなどの操作を伴う複雑なクエリでは、1 つまたは複数のチャンクの work_memを使用できます。
  • 並列操作: 複数の並列バックエンドにまたがるクエリの場合、各バックエンドが 1 つまたは複数のチャンクの work_memを使用する可能性があります。

work_memの監視と調整

システムのパフォーマンスを継続的に監視し、必要に応じて work_mem を調整することが不可欠です。主に、並べ替えやハッシュ操作に関連するクエリの実行時間が遅い場合です。 Azure portal で使用できるツールを使用してパフォーマンスを監視する方法を次に示します。

細かい調整

work_mem パラメーターの管理中は、多くの場合、グローバル値を設定するのではなく、細かい調整アプローチを採用する方が効率的です。 この方法により、プロセスとユーザーの特定のニーズに基づいてメモリを慎重に割り当てることができます。 また、メモリ不足の問題が発生するリスクも最小限に抑えられます。 その方法を次に示します。

  • ユーザー レベル: 特定のユーザーが主に集計タスクまたはレポート タスクに関与している場合は、そのユーザーの work_mem 値をカスタマイズすることを検討してください。 ALTER ROLE コマンドを使用して、ユーザーの操作のパフォーマンスを向上させます。

  • 関数/プロシージャ レベル: 特定の関数またはプロシージャが大量の一時ファイルを生成している場合は、特定の関数またはプロシージャ レベルで work_mem 値を増やすと役立ちます。 ALTER FUNCTIONまたは ALTER PROCEDURE コマンドを使用して、これらの操作により多くのメモリを割り当てます。

  • データベース レベル: 特定のデータベースのみが多数の一時ファイルを生成している場合は、データベース レベルで work_mem を変更します。

  • グローバル レベル: システムの分析で、ほとんどのクエリで小さな一時ファイルが生成されているのに、大きなファイルが作成されているのはごくわずかである場合、 work_mem 値をグローバルに増やすことが賢明な場合があります。 このアクションにより、ほとんどのクエリでメモリ内の処理が容易になるため、ディスク ベースの操作を回避し、効率を向上させることができます。 ただし、サーバーのメモリ使用率は常に注意して監視し、増加した work_mem 値を確実に処理できるようにします。

並べ替え操作の最小work_mem値の決定

特定のクエリ (特に並べ替え処理中に一時ディスク ファイルを生成するクエリ) の最小 work_mem 値を見つけるには、まず、クエリの実行中に生成される一時ファイル サイズを考慮します。 たとえば、クエリで 20 MB の一時ファイルが生成されている場合は、次のようになります。

  1. psql または任意の PostgreSQL クライアントを使用してデータベースに接続します。
  2. メモリ内での処理時に追加のヘッダーを考慮するために、初期 work_mem 値を 20 MB より少し高く設定します。 SET work_mem TO '25MB'などのコマンドを使用します。
  3. 同じセッションで問題のあるクエリに対して EXPLAIN ANALYZE を実行します。
  4. "Sort Method: quicksort Memory: xkB"の出力を確認します。 "external merge Disk: xkB"を示す場合は、work_mem値を段階的に上げ、"quicksort Memory"が表示されるまで再テストします。 "quicksort Memory"の外観は、クエリがメモリ内で動作していることを示します。
  5. この方法を使用して値を決定したら、運用上のニーズに合わせて、グローバルに、またはより詳細なレベル (前述) に適用できます。

autovacuum_work_mem

特性 価値
カテゴリ リソース使用量/メモリ
Description 各自動バキューム worker プロセスで使用される最大メモリを設定します。
データの種類 整数
既定値 -1
使用できる値 -1-2097151
パラメーターのタイプ dynamic
Documentation autovacuum_work_mem

コミットタイムスタンプバッファー

特性 価値
カテゴリ リソース使用量/メモリ
Description コミット タイムスタンプ キャッシュに使用される専用バッファー プールのサイズを設定します。 この値をshared_buffersの分数として決定するには、0 を指定します。
データの種類 整数
既定値 1024
使用できる値 0-131072
パラメーターのタイプ 静的
Documentation `commit_timestamp_buffers`

動的共有メモリータイプ

特性 価値
カテゴリ リソース使用量/メモリ
Description 使用されている動的共有メモリの実装を選択します。
データの種類 リスト
既定値 posix
使用できる値 posix
パラメーターのタイプ 読み取り専用
Documentation dynamic_shared_memory_type

hash_mem_multiplier

特性 価値
カテゴリ リソース使用量/メモリ
Description ハッシュ テーブルに使用する "work_mem" の倍数。
データの種類 numeric
既定値 2
使用できる値 1-1000
パラメーターのタイプ dynamic
Documentation hash_mem_multiplier

huge_pages

特性 価値
カテゴリ リソース使用量/メモリ
Description Linux または Windows での巨大なページの使用。
データの種類 リスト
既定値 try
使用できる値 on,off,try
パラメーターのタイプ 静的
Documentation 大きなページ

Description

巨大なページは、より大きなブロックでメモリを管理できる機能です。 通常、標準の 4 KB ページとは対照的に、最大 2 MB のブロックを管理できます。

巨大なページを使用すると、CPU を効果的にオフロードするパフォーマンス上の利点が得られます。

  • 変換ルックアサイド バッファー (TLB) ミスの減少など、メモリ管理タスクに関連するオーバーヘッドを削減します。
  • メモリ管理に必要な時間を短縮します。

具体的には、PostgreSQL では、共有メモリ領域にのみ巨大なページを使用できます。 共有バッファーには、共有メモリ領域の重要な部分が割り当てられます。

もう 1 つの利点は、巨大なページが共有メモリ領域をディスクにスワップするのを防ぎ、パフォーマンスをさらに安定させるということです。

推奨事項

  • 大量のメモリ リソースを持つサーバーの場合は、巨大なページを無効にしないでください。 巨大なページを無効にすると、パフォーマンスが低下する可能性があります。
  • 巨大なページをサポートしていない小規模なサーバーから始めて、そのサーバーにスケールアップする場合は、シームレスな移行と最適なパフォーマンスを得るために、 huge_pages 設定を TRY に維持します。

Azure 固有の注

4 つ以上の仮想コアを持つサーバーの場合、基になるオペレーティング システムから巨大なページが自動的に割り当てられます。 この機能は、仮想コアが 4 つ未満のサーバーでは使用できません。 shared_buffersの変更など、共有メモリの設定が変更されると、膨大なページの数が自動的に調整されます。

huge_page_size

特性 価値
カテゴリ リソース使用量/メモリ
Description 要求する必要がある巨大なページのサイズです。
データの種類 整数
既定値 0
使用できる値 0
パラメーターのタイプ 読み取り専用
Documentation huge_page_size

io_combine_limit

特性 価値
カテゴリ リソース使用量/メモリ
Description データの読み取りと書き込みのサイズに関する制限。
データの種類 整数
既定値 16
使用できる値 16
パラメーターのタイプ 読み取り専用
Documentation io_combine_limit

logical_decoding_work_mem

特性 価値
カテゴリ リソース使用量/メモリ
Description 論理デコードに使用する最大メモリを設定します。 この量のメモリは、ディスクにスピルする前に、各内部並べ替えバッファーで使用できます。
データの種類 整数
既定値 65536
使用できる値 64-2147483647
パラメーターのタイプ dynamic
Documentation logical_decoding_work_mem (論理デコーディングワークメモリ)

maintenance_work_mem

特性 価値
カテゴリ リソース使用量/メモリ
Description メンテナンス操作に使用する最大メモリを設定します。 これには、VACUUM や CREATE INDEX などの操作が含まれます。
データの種類 整数
既定値 サーバーに割り当てられているリソース (仮想コア、RAM、またはディスク領域) によって異なります。
使用できる値 1024-2097151
パラメーターのタイプ dynamic
Documentation maintenance_work_mem

Description

maintenance_work_mem は PostgreSQL の構成パラメーターです。 VACUUM、CREATE INDEX、ALTER TABLEなど、メンテナンス操作に割り当てられるメモリの量が制御されます。 クエリ操作のメモリ割り当てに影響する work_memとは異なり、 maintenance_work_mem はデータベース構造を維持および最適化するタスク用に予約されています。

![注] maintenance_work_mem を過度にアグレッシブな値に設定すると、システムのメモリ不足エラーが定期的に発生する可能性があります。 このパラメーターを変更する前に、サーバーで使用可能なメモリの量と、前に説明したタスクにメモリを割り当てることができる同時実行操作の数を理解することが非常に重要です。

重要なポイント

  • バキューム メモリ キャップ: maintenance_work_memを増やして消滅タプルのクリーンアップを高速化したい場合は、VACUUMには識別子収集に制限があるため、注意が必要です。 このプロセスでは、最大 1 GB のメモリのみを使用できます。
  • 自動バキュームのメモリの分離: autovacuum_work_mem 設定を使用して、自動バキューム操作が個別に使用するメモリを制御できます。 この設定は、 maintenance_work_memのサブセットとして機能します。 他のメンテナンス タスクやデータ定義操作のメモリ割り当てに影響を与えずに、自動バキュームが使用するメモリの量を決定できます。

Azure 固有の注

maintenance_work_mem サーバー パラメーターの既定値は、Azure Database for PostgreSQL フレキシブル サーバーのインスタンスをプロビジョニングするときに、そのコンピューティング用に選んだ製品名に基づいて計算されます。 その後、フレキシブル サーバーをサポートするコンピューティングに対する製品選択が変更された場合、そのインスタンスの maintenance_work_mem サーバー パラメーターの既定値に影響が及ぶことはありません。

インスタンスに割り当てられた製品を変更するたびに、次の数式の値に従って、 maintenance_work_mem パラメーターの値も調整する必要があります。

maintenance_work_mem の値の計算に使用される数式は (long)(82.5 * ln(memoryGiB) + 40) * 1024 です。

前の数式に基づき、プロビジョニングされたメモリ容量に応じてこのサーバー パラメーターに設定される値を次の表に示します。

メモリ サイズ maintenance_work_mem
2 GiB 99,328 KiB
4 GiB 157,696 KiB
8 GiB 216,064 KiB
16 GiB 274,432 KiB
32 GiB 332,800 KiB
48 GiB 367,616 KiB
64 GiB 392,192 KiB
80 GiB 410,624 KiB
128 GiB 450,560 KiB
160 GiB 468,992 KiB
192 GiB 484,352 KiB
256 GiB 508,928 KiB
384 GiB 542,720 KiB
432 GiB 552,960 KiB
672 GiB 590,848 KiB

max_prepared_transactions（最大準備済みトランザクション）

特性 価値
カテゴリ リソース使用量/メモリ
Description 同時に準備されたトランザクションの最大数を設定します。
データの種類 整数
既定値 0
使用できる値 0-262143
パラメーターのタイプ 静的
Documentation max_prepared_transactions

max_stack_depth (最大スタック深度)

特性 価値
カテゴリ リソース使用量/メモリ
Description スタックの最大深度を KB 単位で設定します。
データの種類 整数
既定値 2048
使用できる値 2048
パラメーターのタイプ 読み取り専用
Documentation max_stack_depth

min_dynamic_shared_memory

特性 価値
カテゴリ リソース使用量/メモリ
Description 起動時に予約された動的共有メモリの量です。
データの種類 整数
既定値 0
使用できる値 0
パラメーターのタイプ 読み取り専用
Documentation min_dynamic_shared_memory

multixact_member_buffers

特性 価値
カテゴリ リソース使用量/メモリ
Description MultiXact メンバー キャッシュに使用される専用バッファー プールのサイズを設定します。
データの種類 整数
既定値 32
使用できる値 16-131072
パラメーターのタイプ 静的
Documentation multixact_member_buffers

multixact_offset_buffers

特性 価値
カテゴリ リソース使用量/メモリ
Description MultiXact オフセット キャッシュに使用される専用バッファー プールのサイズを設定します。
データの種類 整数
既定値 16
使用できる値 16-131072
パラメーターのタイプ 静的
Documentation multixact_offset_buffers

notify_buffers

特性 価値
カテゴリ リソース使用量/メモリ
Description LISTEN/NOTIFY メッセージ キャッシュに使用される専用バッファー プールのサイズを設定します。
データの種類 整数
既定値 16
使用できる値 16-131072
パラメーターのタイプ 静的
Documentation notify_buffers

シリアライズ可能なバッファ

特性 価値
カテゴリ リソース使用量/メモリ
Description シリアル化可能なトランザクション キャッシュに使用される専用バッファー プールのサイズを設定します。
データの種類 整数
既定値 32
使用できる値 16-131072
パラメーターのタイプ 静的
Documentation シリアライズ可能バッファ

共有バッファー

特性 価値
カテゴリ リソース使用量/メモリ
Description サーバーによって使用される共有メモリ バッファーの数を設定します。
データの種類 整数
既定値 サーバーに割り当てられているリソース (仮想コア、RAM、またはディスク領域) によって異なります。
使用できる値 16-1073741823
パラメーターのタイプ 静的
Documentation shared_buffers

Description

shared_buffers構成パラメーターは、データをバッファリングするために PostgreSQL データベースに割り当てられるシステム メモリの量を決定します。 これは、すべてのデータベース プロセスからアクセスできる一元化されたメモリ プールとして機能します。

データが必要な場合、データベース プロセスは最初に共有バッファーをチェックします。 必要なデータが存在する場合は、すばやく取得され、より時間のかかるディスク読み取りをバイパスします。 共有バッファーは、データベース プロセスとディスク間の仲介役として機能し、必要な I/O 操作の数を効果的に減らします。

Azure 固有の注

shared_buffers サーバー パラメーターの既定値は、Azure Database for PostgreSQL フレキシブル サーバーのインスタンスをプロビジョニングするときに、そのコンピューティング用に選んだ製品名に基づいて計算されます。 フレキシブル サーバーをサポートするコンピューティングに対する製品選択の後続の変更は、そのインスタンスの shared_buffers サーバー パラメーターの既定値には影響しません。

インスタンスに割り当てられた製品を変更するたびに、次の数式の値に従って、 shared_buffers パラメーターの値も調整する必要があります。

最大 2 GiB のメモリを持つ仮想マシンの場合、 shared_buffers の値の計算に使用される数式は memoryGib * 16384。

2 GiB を超える仮想マシンの場合、 shared_buffers の値の計算に使用される数式は memoryGib * 32768。

前の数式に基づき、プロビジョニングされたメモリ容量に応じてこのサーバー パラメーターに設定される値を次の表に示します。

メモリ サイズ 共有バッファー
2 GiB 32768
4 GiB 131072
8 GiB 262144
16 GiB 524288
32 GiB 1048576
48 GiB 1572864
64 GiB 2097152
80 GiB 2621440
128 GiB 4194304
160 GiB 5242880
192 GiB 6291456
256 GiB 8388608
384 GiB 12582912
432 GiB 14155776
672 GiB 22020096

共有メモリタイプ

特性 価値
カテゴリ リソース使用量/メモリ
Description メイン共有メモリ領域に使用される共有メモリ実装を選択します。
データの種類 リスト
既定値 mmap
使用できる値 mmap
パラメーターのタイプ 読み取り専用
Documentation shared_memory_type

サブトランザクションバッファ

特性 価値
カテゴリ リソース使用量/メモリ
Description サブトランザクション キャッシュに使用される専用バッファー プールのサイズを設定します。 この値をshared_buffersの分数として決定するには、0 を指定します。
データの種類 整数
既定値 1024
使用できる値 0-131072
パラメーターのタイプ 静的
Documentation サブトランザクションバッファ

テンポラリーバッファー

特性 価値
カテゴリ リソース使用量/メモリ
Description 各セッションで使用される一時バッファーの最大数を設定します。
データの種類 整数
既定値 1024
使用できる値 100-1073741823
パラメーターのタイプ dynamic
Documentation temp_buffers

トランザクションバッファ

特性 価値
カテゴリ リソース使用量/メモリ
Description トランザクション状態キャッシュに使用される専用バッファー プールのサイズを設定します。 この値をshared_buffersの分数として決定するには、0 を指定します。
データの種類 整数
既定値 1024
使用できる値 0-131072
パラメーターのタイプ 静的
Documentation transaction_buffers

vacuum_buffer_usage_limit

特性 価値
カテゴリ リソース使用量/メモリ
Description VACUUM、ANALYZE、自動バキュームのバッファー プール サイズを設定します。
データの種類 整数
既定値 2048
使用できる値 0-16777216
パラメーターのタイプ dynamic
Documentation vacuum_buffer_usage_limit

作業メモリー

特性 価値
カテゴリ リソース使用量/メモリ
Description クエリ ワークスペースに使用する最大メモリを設定します。 この多くのメモリは、一時ディスク ファイルに切り替える前に、各内部並べ替え操作とハッシュ テーブルで使用できます。
データの種類 整数
既定値 4096
使用できる値 4096-2097151
パラメーターのタイプ dynamic
Documentation work_mem

Description

PostgreSQL の work_mem パラメーターは、各データベース セッションのプライベート メモリ領域内の特定の内部操作に割り当てられるメモリの量を制御します。 これらの操作の例として、並べ替えとハッシュがあります。

共有メモリ領域にある共有バッファーとは異なり、 work_mem はセッションごとまたはクエリごとのプライベート メモリ領域に割り当てられます。 適切な work_mem サイズを設定することで、これらの操作の効率を大幅に向上させ、一時データをディスクに書き込む必要性を減らすことができます。

重要なポイント

  • プライベート接続メモリ: work_mem は、各データベース セッションで使用されるプライベート メモリの一部です。 このメモリは、 shared_buffers が使用する共有メモリ領域とは異なります。
  • クエリ固有の使用方法: すべてのセッションまたはクエリで work_memが使用されるわけではありません。 SELECT 1のような単純なクエリでは、work_memが必要な可能性はほとんどありません。 ただし、並べ替えやハッシュなどの操作を伴う複雑なクエリでは、1 つまたは複数のチャンクの work_memを使用できます。
  • 並列操作: 複数の並列バックエンドにまたがるクエリの場合、各バックエンドが 1 つまたは複数のチャンクの work_memを使用する可能性があります。

work_memの監視と調整

システムのパフォーマンスを継続的に監視し、必要に応じて work_mem を調整することが不可欠です。主に、並べ替えやハッシュ操作に関連するクエリの実行時間が遅い場合です。 Azure portal で使用できるツールを使用してパフォーマンスを監視する方法を次に示します。

細かい調整

work_mem パラメーターの管理中は、多くの場合、グローバル値を設定するのではなく、細かい調整アプローチを採用する方が効率的です。 この方法により、プロセスとユーザーの特定のニーズに基づいてメモリを慎重に割り当てることができます。 また、メモリ不足の問題が発生するリスクも最小限に抑えられます。 その方法を次に示します。

  • ユーザー レベル: 特定のユーザーが主に集計タスクまたはレポート タスクに関与している場合は、そのユーザーの work_mem 値をカスタマイズすることを検討してください。 ALTER ROLE コマンドを使用して、ユーザーの操作のパフォーマンスを向上させます。

  • 関数/プロシージャ レベル: 特定の関数またはプロシージャが大量の一時ファイルを生成している場合は、特定の関数またはプロシージャ レベルで work_mem 値を増やすと役立ちます。 ALTER FUNCTIONまたは ALTER PROCEDURE コマンドを使用して、これらの操作により多くのメモリを割り当てます。

  • データベース レベル: 特定のデータベースのみが多数の一時ファイルを生成している場合は、データベース レベルで work_mem を変更します。

  • グローバル レベル: システムの分析で、ほとんどのクエリで小さな一時ファイルが生成されているのに、大きなファイルが作成されているのはごくわずかである場合、 work_mem 値をグローバルに増やすことが賢明な場合があります。 このアクションにより、ほとんどのクエリでメモリ内の処理が容易になるため、ディスク ベースの操作を回避し、効率を向上させることができます。 ただし、サーバーのメモリ使用率は常に注意して監視し、増加した work_mem 値を確実に処理できるようにします。

並べ替え操作の最小work_mem値の決定

特定のクエリ (特に並べ替え処理中に一時ディスク ファイルを生成するクエリ) の最小 work_mem 値を見つけるには、まず、クエリの実行中に生成される一時ファイル サイズを考慮します。 たとえば、クエリで 20 MB の一時ファイルが生成されている場合は、次のようになります。

  1. psql または任意の PostgreSQL クライアントを使用してデータベースに接続します。
  2. メモリ内での処理時に追加のヘッダーを考慮するために、初期 work_mem 値を 20 MB より少し高く設定します。 SET work_mem TO '25MB'などのコマンドを使用します。
  3. 同じセッションで問題のあるクエリに対して EXPLAIN ANALYZE を実行します。
  4. "Sort Method: quicksort Memory: xkB"の出力を確認します。 "external merge Disk: xkB"を示す場合は、work_mem値を段階的に上げ、"quicksort Memory"が表示されるまで再テストします。 "quicksort Memory"の外観は、クエリがメモリ内で動作していることを示します。
  5. この方法を使用して値を決定したら、運用上のニーズに合わせて、グローバルに、またはより詳細なレベル (前述) に適用できます。

autovacuum_work_mem

特性 価値
カテゴリ リソース使用量/メモリ
Description 各自動バキューム worker プロセスで使用される最大メモリを設定します。
データの種類 整数
既定値 -1
使用できる値 -1-2097151
パラメーターのタイプ dynamic
Documentation autovacuum_work_mem

動的共有メモリータイプ

特性 価値
カテゴリ リソース使用量/メモリ
Description 使用されている動的共有メモリの実装を選択します。
データの種類 リスト
既定値 posix
使用できる値 posix
パラメーターのタイプ 読み取り専用
Documentation dynamic_shared_memory_type

hash_mem_multiplier

特性 価値
カテゴリ リソース使用量/メモリ
Description ハッシュ テーブルに使用する work_mem の倍数。
データの種類 numeric
既定値 2
使用できる値 1-1000
パラメーターのタイプ dynamic
Documentation hash_mem_multiplier

huge_pages

特性 価値
カテゴリ リソース使用量/メモリ
Description 巨大なメモリ ページの使用を有効または無効にします。 この設定は、仮想コア数が 4 未満のサーバーには適用されません。
データの種類 リスト
既定値 try
使用できる値 on,off,try
パラメーターのタイプ 静的
Documentation 大きなページ

Description

巨大なページは、より大きなブロックでメモリを管理できる機能です。 通常、標準の 4 KB ページとは対照的に、最大 2 MB のブロックを管理できます。

巨大なページを使用すると、CPU を効果的にオフロードするパフォーマンス上の利点が得られます。

  • 変換ルックアサイド バッファー (TLB) ミスの減少など、メモリ管理タスクに関連するオーバーヘッドを削減します。
  • メモリ管理に必要な時間を短縮します。

具体的には、PostgreSQL では、共有メモリ領域にのみ巨大なページを使用できます。 共有バッファーには、共有メモリ領域の重要な部分が割り当てられます。

もう 1 つの利点は、巨大なページが共有メモリ領域をディスクにスワップするのを防ぎ、パフォーマンスをさらに安定させるということです。

推奨事項

  • 大量のメモリ リソースを持つサーバーの場合は、巨大なページを無効にしないでください。 巨大なページを無効にすると、パフォーマンスが低下する可能性があります。
  • 巨大なページをサポートしていない小規模なサーバーから始めて、そのサーバーにスケールアップする場合は、シームレスな移行と最適なパフォーマンスを得るために、 huge_pages 設定を TRY に維持します。

Azure 固有の注

4 つ以上の仮想コアを持つサーバーの場合、基になるオペレーティング システムから巨大なページが自動的に割り当てられます。 この機能は、仮想コアが 4 つ未満のサーバーでは使用できません。 shared_buffersの変更など、共有メモリの設定が変更されると、膨大なページの数が自動的に調整されます。

huge_page_size

特性 価値
カテゴリ リソース使用量/メモリ
Description 要求する必要がある巨大なページのサイズです。
データの種類 整数
既定値 0
使用できる値 0
パラメーターのタイプ 読み取り専用
Documentation huge_page_size

logical_decoding_work_mem

特性 価値
カテゴリ リソース使用量/メモリ
Description 論理デコードに使用する最大メモリを設定します。
データの種類 整数
既定値 65536
使用できる値 64-2147483647
パラメーターのタイプ dynamic
Documentation logical_decoding_work_mem (論理デコーディングワークメモリ)

maintenance_work_mem

特性 価値
カテゴリ リソース使用量/メモリ
Description VACUUM、インデックスの作成などのメンテナンス操作に使用する最大メモリを設定します。
データの種類 整数
既定値 サーバーに割り当てられているリソース (仮想コア、RAM、またはディスク領域) によって異なります。
使用できる値 1024-2097151
パラメーターのタイプ dynamic
Documentation maintenance_work_mem

Description

maintenance_work_mem は PostgreSQL の構成パラメーターです。 VACUUM、CREATE INDEX、ALTER TABLEなど、メンテナンス操作に割り当てられるメモリの量が制御されます。 クエリ操作のメモリ割り当てに影響する work_memとは異なり、 maintenance_work_mem はデータベース構造を維持および最適化するタスク用に予約されています。

![注] maintenance_work_mem を過度にアグレッシブな値に設定すると、システムのメモリ不足エラーが定期的に発生する可能性があります。 このパラメーターを変更する前に、サーバーで使用可能なメモリの量と、前に説明したタスクにメモリを割り当てることができる同時実行操作の数を理解することが非常に重要です。

重要なポイント

  • バキューム メモリ キャップ: maintenance_work_memを増やして消滅タプルのクリーンアップを高速化したい場合は、VACUUMには識別子収集に制限があるため、注意が必要です。 このプロセスでは、最大 1 GB のメモリのみを使用できます。
  • 自動バキュームのメモリの分離: autovacuum_work_mem 設定を使用して、自動バキューム操作が個別に使用するメモリを制御できます。 この設定は、 maintenance_work_memのサブセットとして機能します。 他のメンテナンス タスクやデータ定義操作のメモリ割り当てに影響を与えずに、自動バキュームが使用するメモリの量を決定できます。

Azure 固有の注

maintenance_work_mem サーバー パラメーターの既定値は、Azure Database for PostgreSQL フレキシブル サーバーのインスタンスをプロビジョニングするときに、そのコンピューティング用に選んだ製品名に基づいて計算されます。 その後、フレキシブル サーバーをサポートするコンピューティングに対する製品選択が変更された場合、そのインスタンスの maintenance_work_mem サーバー パラメーターの既定値に影響が及ぶことはありません。

インスタンスに割り当てられた製品を変更するたびに、次の数式の値に従って、 maintenance_work_mem パラメーターの値も調整する必要があります。

maintenance_work_mem の値の計算に使用される数式は (long)(82.5 * ln(memoryGiB) + 40) * 1024 です。

前の数式に基づき、プロビジョニングされたメモリ容量に応じてこのサーバー パラメーターに設定される値を次の表に示します。

メモリ サイズ maintenance_work_mem
2 GiB 99,328 KiB
4 GiB 157,696 KiB
8 GiB 216,064 KiB
16 GiB 274,432 KiB
32 GiB 332,800 KiB
48 GiB 367,616 KiB
64 GiB 392,192 KiB
80 GiB 410,624 KiB
128 GiB 450,560 KiB
160 GiB 468,992 KiB
192 GiB 484,352 KiB
256 GiB 508,928 KiB
384 GiB 542,720 KiB
432 GiB 552,960 KiB
672 GiB 590,848 KiB

max_prepared_transactions（最大準備済みトランザクション）

特性 価値
カテゴリ リソース使用量/メモリ
Description 同時に準備されたトランザクションの最大数を設定します。 レプリカ サーバーを実行する場合は、このパラメーターをプライマリ サーバーの値以上に設定する必要があります。
データの種類 整数
既定値 0
使用できる値 0-262143
パラメーターのタイプ 静的
Documentation max_prepared_transactions

max_stack_depth (最大スタック深度)

特性 価値
カテゴリ リソース使用量/メモリ
Description スタックの最大深度を KB 単位で設定します。
データの種類 整数
既定値 2048
使用できる値 2048
パラメーターのタイプ 読み取り専用
Documentation max_stack_depth

min_dynamic_shared_memory

特性 価値
カテゴリ リソース使用量/メモリ
Description 起動時に予約された動的共有メモリの量です。
データの種類 整数
既定値 0
使用できる値 0
パラメーターのタイプ 読み取り専用
Documentation min_dynamic_shared_memory

共有バッファー

特性 価値
カテゴリ リソース使用量/メモリ
Description サーバーによって使用される共有メモリ バッファーの数を設定します。 単位は 8 KB です。 許可される値は、使用可能なメモリの 10% から 75% の範囲内です。
データの種類 整数
既定値 サーバーに割り当てられているリソース (仮想コア、RAM、またはディスク領域) によって異なります。
使用できる値 16-1073741823
パラメーターのタイプ 静的
Documentation shared_buffers

Description

shared_buffers構成パラメーターは、データをバッファリングするために PostgreSQL データベースに割り当てられるシステム メモリの量を決定します。 これは、すべてのデータベース プロセスからアクセスできる一元化されたメモリ プールとして機能します。

データが必要な場合、データベース プロセスは最初に共有バッファーをチェックします。 必要なデータが存在する場合は、すばやく取得され、より時間のかかるディスク読み取りをバイパスします。 共有バッファーは、データベース プロセスとディスク間の仲介役として機能し、必要な I/O 操作の数を効果的に減らします。

Azure 固有の注

shared_buffers サーバー パラメーターの既定値は、Azure Database for PostgreSQL フレキシブル サーバーのインスタンスをプロビジョニングするときに、そのコンピューティング用に選んだ製品名に基づいて計算されます。 フレキシブル サーバーをサポートするコンピューティングに対する製品選択の後続の変更は、そのインスタンスの shared_buffers サーバー パラメーターの既定値には影響しません。

インスタンスに割り当てられた製品を変更するたびに、次の数式の値に従って、 shared_buffers パラメーターの値も調整する必要があります。

最大 2 GiB のメモリを持つ仮想マシンの場合、 shared_buffers の値の計算に使用される数式は memoryGib * 16384。

2 GiB を超える仮想マシンの場合、 shared_buffers の値の計算に使用される数式は memoryGib * 32768。

前の数式に基づき、プロビジョニングされたメモリ容量に応じてこのサーバー パラメーターに設定される値を次の表に示します。

メモリ サイズ 共有バッファー
2 GiB 32768
4 GiB 131072
8 GiB 262144
16 GiB 524288
32 GiB 1048576
48 GiB 1572864
64 GiB 2097152
80 GiB 2621440
128 GiB 4194304
160 GiB 5242880
192 GiB 6291456
256 GiB 8388608
384 GiB 12582912
432 GiB 14155776
672 GiB 22020096

共有メモリタイプ

特性 価値
カテゴリ リソース使用量/メモリ
Description メイン共有メモリ領域に使用される共有メモリ実装を選択します。
データの種類 リスト
既定値 mmap
使用できる値 mmap
パラメーターのタイプ 読み取り専用
Documentation shared_memory_type

テンポラリーバッファー

特性 価値
カテゴリ リソース使用量/メモリ
Description 各データベース セッションで使用される一時バッファーの最大数を設定します。
データの種類 整数
既定値 1024
使用できる値 100-1073741823
パラメーターのタイプ dynamic
Documentation temp_buffers

vacuum_buffer_usage_limit

特性 価値
カテゴリ リソース使用量/メモリ
Description VACUUM、ANALYZE、自動バキュームのバッファー プール サイズを設定します。
データの種類 整数
既定値 256
使用できる値 0-16777216
パラメーターのタイプ dynamic
Documentation vacuum_buffer_usage_limit

作業メモリー

特性 価値
カテゴリ リソース使用量/メモリ
Description それを超えると一時ディスク ファイルへの書き込みが行われる、内部並べ替え操作とハッシュ テーブルによって使用されたメモリの量を設定します。
データの種類 整数
既定値 4096
使用できる値 4096-2097151
パラメーターのタイプ dynamic
Documentation work_mem

Description

PostgreSQL の work_mem パラメーターは、各データベース セッションのプライベート メモリ領域内の特定の内部操作に割り当てられるメモリの量を制御します。 これらの操作の例として、並べ替えとハッシュがあります。

共有メモリ領域にある共有バッファーとは異なり、 work_mem はセッションごとまたはクエリごとのプライベート メモリ領域に割り当てられます。 適切な work_mem サイズを設定することで、これらの操作の効率を大幅に向上させ、一時データをディスクに書き込む必要性を減らすことができます。

重要なポイント

  • プライベート接続メモリ: work_mem は、各データベース セッションで使用されるプライベート メモリの一部です。 このメモリは、 shared_buffers が使用する共有メモリ領域とは異なります。
  • クエリ固有の使用方法: すべてのセッションまたはクエリで work_memが使用されるわけではありません。 SELECT 1のような単純なクエリでは、work_memが必要な可能性はほとんどありません。 ただし、並べ替えやハッシュなどの操作を伴う複雑なクエリでは、1 つまたは複数のチャンクの work_memを使用できます。
  • 並列操作: 複数の並列バックエンドにまたがるクエリの場合、各バックエンドが 1 つまたは複数のチャンクの work_memを使用する可能性があります。

work_memの監視と調整

システムのパフォーマンスを継続的に監視し、必要に応じて work_mem を調整することが不可欠です。主に、並べ替えやハッシュ操作に関連するクエリの実行時間が遅い場合です。 Azure portal で使用できるツールを使用してパフォーマンスを監視する方法を次に示します。

細かい調整

work_mem パラメーターの管理中は、多くの場合、グローバル値を設定するのではなく、細かい調整アプローチを採用する方が効率的です。 この方法により、プロセスとユーザーの特定のニーズに基づいてメモリを慎重に割り当てることができます。 また、メモリ不足の問題が発生するリスクも最小限に抑えられます。 その方法を次に示します。

  • ユーザー レベル: 特定のユーザーが主に集計タスクまたはレポート タスクに関与している場合は、そのユーザーの work_mem 値をカスタマイズすることを検討してください。 ALTER ROLE コマンドを使用して、ユーザーの操作のパフォーマンスを向上させます。

  • 関数/プロシージャ レベル: 特定の関数またはプロシージャが大量の一時ファイルを生成している場合は、特定の関数またはプロシージャ レベルで work_mem 値を増やすと役立ちます。 ALTER FUNCTIONまたは ALTER PROCEDURE コマンドを使用して、これらの操作により多くのメモリを割り当てます。

  • データベース レベル: 特定のデータベースのみが多数の一時ファイルを生成している場合は、データベース レベルで work_mem を変更します。

  • グローバル レベル: システムの分析で、ほとんどのクエリで小さな一時ファイルが生成されているのに、大きなファイルが作成されているのはごくわずかである場合、 work_mem 値をグローバルに増やすことが賢明な場合があります。 このアクションにより、ほとんどのクエリでメモリ内の処理が容易になるため、ディスク ベースの操作を回避し、効率を向上させることができます。 ただし、サーバーのメモリ使用率は常に注意して監視し、増加した work_mem 値を確実に処理できるようにします。

並べ替え操作の最小work_mem値の決定

特定のクエリ (特に並べ替え処理中に一時ディスク ファイルを生成するクエリ) の最小 work_mem 値を見つけるには、まず、クエリの実行中に生成される一時ファイル サイズを考慮します。 たとえば、クエリで 20 MB の一時ファイルが生成されている場合は、次のようになります。

  1. psql または任意の PostgreSQL クライアントを使用してデータベースに接続します。
  2. メモリ内での処理時に追加のヘッダーを考慮するために、初期 work_mem 値を 20 MB より少し高く設定します。 SET work_mem TO '25MB'などのコマンドを使用します。
  3. 同じセッションで問題のあるクエリに対して EXPLAIN ANALYZE を実行します。
  4. "Sort Method: quicksort Memory: xkB"の出力を確認します。 "external merge Disk: xkB"を示す場合は、work_mem値を段階的に上げ、"quicksort Memory"が表示されるまで再テストします。 "quicksort Memory"の外観は、クエリがメモリ内で動作していることを示します。
  5. この方法を使用して値を決定したら、運用上のニーズに合わせて、グローバルに、またはより詳細なレベル (前述) に適用できます。

autovacuum_work_mem

特性 価値
カテゴリ リソース使用量/メモリ
Description 各自動バキューム worker プロセスで使用される最大メモリを設定します。
データの種類 整数
既定値 -1
使用できる値 -1-2097151
パラメーターのタイプ dynamic
Documentation autovacuum_work_mem

動的共有メモリータイプ

特性 価値
カテゴリ リソース使用量/メモリ
Description 使用されている動的共有メモリの実装を選択します。
データの種類 リスト
既定値 posix
使用できる値 posix
パラメーターのタイプ 読み取り専用
Documentation dynamic_shared_memory_type

hash_mem_multiplier

特性 価値
カテゴリ リソース使用量/メモリ
Description ハッシュ テーブルに使用する work_mem の倍数。
データの種類 numeric
既定値 2
使用できる値 1-1000
パラメーターのタイプ dynamic
Documentation hash_mem_multiplier

huge_pages

特性 価値
カテゴリ リソース使用量/メモリ
Description 巨大なメモリ ページの使用を有効または無効にします。 この設定は、仮想コア数が 4 未満のサーバーには適用されません。
データの種類 リスト
既定値 try
使用できる値 on,off,try
パラメーターのタイプ 静的
Documentation 大きなページ

Description

巨大なページは、より大きなブロックでメモリを管理できる機能です。 通常、標準の 4 KB ページとは対照的に、最大 2 MB のブロックを管理できます。

巨大なページを使用すると、CPU を効果的にオフロードするパフォーマンス上の利点が得られます。

  • 変換ルックアサイド バッファー (TLB) ミスの減少など、メモリ管理タスクに関連するオーバーヘッドを削減します。
  • メモリ管理に必要な時間を短縮します。

具体的には、PostgreSQL では、共有メモリ領域にのみ巨大なページを使用できます。 共有バッファーには、共有メモリ領域の重要な部分が割り当てられます。

もう 1 つの利点は、巨大なページが共有メモリ領域をディスクにスワップするのを防ぎ、パフォーマンスをさらに安定させるということです。

推奨事項

  • 大量のメモリ リソースを持つサーバーの場合は、巨大なページを無効にしないでください。 巨大なページを無効にすると、パフォーマンスが低下する可能性があります。
  • 巨大なページをサポートしていない小規模なサーバーから始めて、そのサーバーにスケールアップする場合は、シームレスな移行と最適なパフォーマンスを得るために、 huge_pages 設定を TRY に維持します。

Azure 固有の注

4 つ以上の仮想コアを持つサーバーの場合、基になるオペレーティング システムから巨大なページが自動的に割り当てられます。 この機能は、仮想コアが 4 つ未満のサーバーでは使用できません。 shared_buffersの変更など、共有メモリの設定が変更されると、膨大なページの数が自動的に調整されます。

huge_page_size

特性 価値
カテゴリ リソース使用量/メモリ
Description 要求する必要がある巨大なページのサイズです。
データの種類 整数
既定値 0
使用できる値 0
パラメーターのタイプ 読み取り専用
Documentation huge_page_size

logical_decoding_work_mem

特性 価値
カテゴリ リソース使用量/メモリ
Description 論理デコードに使用する最大メモリを設定します。
データの種類 整数
既定値 65536
使用できる値 64-2147483647
パラメーターのタイプ dynamic
Documentation logical_decoding_work_mem (論理デコーディングワークメモリ)

maintenance_work_mem

特性 価値
カテゴリ リソース使用量/メモリ
Description VACUUM、インデックスの作成などのメンテナンス操作に使用する最大メモリを設定します。
データの種類 整数
既定値 サーバーに割り当てられているリソース (仮想コア、RAM、またはディスク領域) によって異なります。
使用できる値 1024-2097151
パラメーターのタイプ dynamic
Documentation maintenance_work_mem

Description

maintenance_work_mem は PostgreSQL の構成パラメーターです。 VACUUM、CREATE INDEX、ALTER TABLEなど、メンテナンス操作に割り当てられるメモリの量が制御されます。 クエリ操作のメモリ割り当てに影響する work_memとは異なり、 maintenance_work_mem はデータベース構造を維持および最適化するタスク用に予約されています。

![注] maintenance_work_mem を過度にアグレッシブな値に設定すると、システムのメモリ不足エラーが定期的に発生する可能性があります。 このパラメーターを変更する前に、サーバーで使用可能なメモリの量と、前に説明したタスクにメモリを割り当てることができる同時実行操作の数を理解することが非常に重要です。

重要なポイント

  • バキューム メモリ キャップ: maintenance_work_memを増やして消滅タプルのクリーンアップを高速化したい場合は、VACUUMには識別子収集に制限があるため、注意が必要です。 このプロセスでは、最大 1 GB のメモリのみを使用できます。
  • 自動バキュームのメモリの分離: autovacuum_work_mem 設定を使用して、自動バキューム操作が個別に使用するメモリを制御できます。 この設定は、 maintenance_work_memのサブセットとして機能します。 他のメンテナンス タスクやデータ定義操作のメモリ割り当てに影響を与えずに、自動バキュームが使用するメモリの量を決定できます。

Azure 固有の注

maintenance_work_mem サーバー パラメーターの既定値は、Azure Database for PostgreSQL フレキシブル サーバーのインスタンスをプロビジョニングするときに、そのコンピューティング用に選んだ製品名に基づいて計算されます。 その後、フレキシブル サーバーをサポートするコンピューティングに対する製品選択が変更された場合、そのインスタンスの maintenance_work_mem サーバー パラメーターの既定値に影響が及ぶことはありません。

インスタンスに割り当てられた製品を変更するたびに、次の数式の値に従って、 maintenance_work_mem パラメーターの値も調整する必要があります。

maintenance_work_mem の値の計算に使用される数式は (long)(82.5 * ln(memoryGiB) + 40) * 1024 です。

前の数式に基づき、プロビジョニングされたメモリ容量に応じてこのサーバー パラメーターに設定される値を次の表に示します。

メモリ サイズ maintenance_work_mem
2 GiB 99,328 KiB
4 GiB 157,696 KiB
8 GiB 216,064 KiB
16 GiB 274,432 KiB
32 GiB 332,800 KiB
48 GiB 367,616 KiB
64 GiB 392,192 KiB
80 GiB 410,624 KiB
128 GiB 450,560 KiB
160 GiB 468,992 KiB
192 GiB 484,352 KiB
256 GiB 508,928 KiB
384 GiB 542,720 KiB
432 GiB 552,960 KiB
672 GiB 590,848 KiB

max_prepared_transactions（最大準備済みトランザクション）

特性 価値
カテゴリ リソース使用量/メモリ
Description 同時に準備されたトランザクションの最大数を設定します。 レプリカ サーバーを実行する場合は、このパラメーターをプライマリ サーバーの値以上に設定する必要があります。
データの種類 整数
既定値 0
使用できる値 0-262143
パラメーターのタイプ 静的
Documentation max_prepared_transactions

max_stack_depth (最大スタック深度)

特性 価値
カテゴリ リソース使用量/メモリ
Description スタックの最大深度を KB 単位で設定します。
データの種類 整数
既定値 2048
使用できる値 2048
パラメーターのタイプ 読み取り専用
Documentation max_stack_depth

min_dynamic_shared_memory

特性 価値
カテゴリ リソース使用量/メモリ
Description 起動時に予約された動的共有メモリの量です。
データの種類 整数
既定値 0
使用できる値 0
パラメーターのタイプ 読み取り専用
Documentation min_dynamic_shared_memory

共有バッファー

特性 価値
カテゴリ リソース使用量/メモリ
Description サーバーによって使用される共有メモリ バッファーの数を設定します。 単位は 8 KB です。 許可される値は、使用可能なメモリの 10% から 75% の範囲内です。
データの種類 整数
既定値 サーバーに割り当てられているリソース (仮想コア、RAM、またはディスク領域) によって異なります。
使用できる値 16-1073741823
パラメーターのタイプ 静的
Documentation shared_buffers

Description

shared_buffers構成パラメーターは、データをバッファリングするために PostgreSQL データベースに割り当てられるシステム メモリの量を決定します。 これは、すべてのデータベース プロセスからアクセスできる一元化されたメモリ プールとして機能します。

データが必要な場合、データベース プロセスは最初に共有バッファーをチェックします。 必要なデータが存在する場合は、すばやく取得され、より時間のかかるディスク読み取りをバイパスします。 共有バッファーは、データベース プロセスとディスク間の仲介役として機能し、必要な I/O 操作の数を効果的に減らします。

Azure 固有の注

shared_buffers サーバー パラメーターの既定値は、Azure Database for PostgreSQL フレキシブル サーバーのインスタンスをプロビジョニングするときに、そのコンピューティング用に選んだ製品名に基づいて計算されます。 フレキシブル サーバーをサポートするコンピューティングに対する製品選択の後続の変更は、そのインスタンスの shared_buffers サーバー パラメーターの既定値には影響しません。

インスタンスに割り当てられた製品を変更するたびに、次の数式の値に従って、 shared_buffers パラメーターの値も調整する必要があります。

最大 2 GiB のメモリを持つ仮想マシンの場合、 shared_buffers の値の計算に使用される数式は memoryGib * 16384。

2 GiB を超える仮想マシンの場合、 shared_buffers の値の計算に使用される数式は memoryGib * 32768。

前の数式に基づき、プロビジョニングされたメモリ容量に応じてこのサーバー パラメーターに設定される値を次の表に示します。

メモリ サイズ 共有バッファー
2 GiB 32768
4 GiB 131072
8 GiB 262144
16 GiB 524288
32 GiB 1048576
48 GiB 1572864
64 GiB 2097152
80 GiB 2621440
128 GiB 4194304
160 GiB 5242880
192 GiB 6291456
256 GiB 8388608
384 GiB 12582912
432 GiB 14155776
672 GiB 22020096

共有メモリタイプ

特性 価値
カテゴリ リソース使用量/メモリ
Description メイン共有メモリ領域に使用される共有メモリ実装を選択します。
データの種類 リスト
既定値 mmap
使用できる値 mmap
パラメーターのタイプ 読み取り専用
Documentation shared_memory_type

テンポラリーバッファー

特性 価値
カテゴリ リソース使用量/メモリ
Description 各データベース セッションで使用される一時バッファーの最大数を設定します。
データの種類 整数
既定値 1024
使用できる値 100-1073741823
パラメーターのタイプ dynamic
Documentation temp_buffers

作業メモリー

特性 価値
カテゴリ リソース使用量/メモリ
Description それを超えると一時ディスク ファイルへの書き込みが行われる、内部並べ替え操作とハッシュ テーブルによって使用されたメモリの量を設定します。
データの種類 整数
既定値 4096
使用できる値 4096-2097151
パラメーターのタイプ dynamic
Documentation work_mem

Description

PostgreSQL の work_mem パラメーターは、各データベース セッションのプライベート メモリ領域内の特定の内部操作に割り当てられるメモリの量を制御します。 これらの操作の例として、並べ替えとハッシュがあります。

共有メモリ領域にある共有バッファーとは異なり、 work_mem はセッションごとまたはクエリごとのプライベート メモリ領域に割り当てられます。 適切な work_mem サイズを設定することで、これらの操作の効率を大幅に向上させ、一時データをディスクに書き込む必要性を減らすことができます。

重要なポイント

  • プライベート接続メモリ: work_mem は、各データベース セッションで使用されるプライベート メモリの一部です。 このメモリは、 shared_buffers が使用する共有メモリ領域とは異なります。
  • クエリ固有の使用方法: すべてのセッションまたはクエリで work_memが使用されるわけではありません。 SELECT 1のような単純なクエリでは、work_memが必要な可能性はほとんどありません。 ただし、並べ替えやハッシュなどの操作を伴う複雑なクエリでは、1 つまたは複数のチャンクの work_memを使用できます。
  • 並列操作: 複数の並列バックエンドにまたがるクエリの場合、各バックエンドが 1 つまたは複数のチャンクの work_memを使用する可能性があります。

work_memの監視と調整

システムのパフォーマンスを継続的に監視し、必要に応じて work_mem を調整することが不可欠です。主に、並べ替えやハッシュ操作に関連するクエリの実行時間が遅い場合です。 Azure portal で使用できるツールを使用してパフォーマンスを監視する方法を次に示します。

細かい調整

work_mem パラメーターの管理中は、多くの場合、グローバル値を設定するのではなく、細かい調整アプローチを採用する方が効率的です。 この方法により、プロセスとユーザーの特定のニーズに基づいてメモリを慎重に割り当てることができます。 また、メモリ不足の問題が発生するリスクも最小限に抑えられます。 その方法を次に示します。

  • ユーザー レベル: 特定のユーザーが主に集計タスクまたはレポート タスクに関与している場合は、そのユーザーの work_mem 値をカスタマイズすることを検討してください。 ALTER ROLE コマンドを使用して、ユーザーの操作のパフォーマンスを向上させます。

  • 関数/プロシージャ レベル: 特定の関数またはプロシージャが大量の一時ファイルを生成している場合は、特定の関数またはプロシージャ レベルで work_mem 値を増やすと役立ちます。 ALTER FUNCTIONまたは ALTER PROCEDURE コマンドを使用して、これらの操作により多くのメモリを割り当てます。

  • データベース レベル: 特定のデータベースのみが多数の一時ファイルを生成している場合は、データベース レベルで work_mem を変更します。

  • グローバル レベル: システムの分析で、ほとんどのクエリで小さな一時ファイルが生成されているのに、大きなファイルが作成されているのはごくわずかである場合、 work_mem 値をグローバルに増やすことが賢明な場合があります。 このアクションにより、ほとんどのクエリでメモリ内の処理が容易になるため、ディスク ベースの操作を回避し、効率を向上させることができます。 ただし、サーバーのメモリ使用率は常に注意して監視し、増加した work_mem 値を確実に処理できるようにします。

並べ替え操作の最小work_mem値の決定

特定のクエリ (特に並べ替え処理中に一時ディスク ファイルを生成するクエリ) の最小 work_mem 値を見つけるには、まず、クエリの実行中に生成される一時ファイル サイズを考慮します。 たとえば、クエリで 20 MB の一時ファイルが生成されている場合は、次のようになります。

  1. psql または任意の PostgreSQL クライアントを使用してデータベースに接続します。
  2. メモリ内での処理時に追加のヘッダーを考慮するために、初期 work_mem 値を 20 MB より少し高く設定します。 SET work_mem TO '25MB'などのコマンドを使用します。
  3. 同じセッションで問題のあるクエリに対して EXPLAIN ANALYZE を実行します。
  4. "Sort Method: quicksort Memory: xkB"の出力を確認します。 "external merge Disk: xkB"を示す場合は、work_mem値を段階的に上げ、"quicksort Memory"が表示されるまで再テストします。 "quicksort Memory"の外観は、クエリがメモリ内で動作していることを示します。
  5. この方法を使用して値を決定したら、運用上のニーズに合わせて、グローバルに、またはより詳細なレベル (前述) に適用できます。

autovacuum_work_mem

特性 価値
カテゴリ リソース使用量/メモリ
Description 各自動バキューム worker プロセスで使用される最大メモリを設定します。
データの種類 整数
既定値 -1
使用できる値 -1-2097151
パラメーターのタイプ dynamic
Documentation autovacuum_work_mem

動的共有メモリータイプ

特性 価値
カテゴリ リソース使用量/メモリ
Description 使用されている動的共有メモリの実装を選択します。
データの種類 リスト
既定値 posix
使用できる値 posix
パラメーターのタイプ 読み取り専用
Documentation dynamic_shared_memory_type

hash_mem_multiplier

特性 価値
カテゴリ リソース使用量/メモリ
Description ハッシュ テーブルに使用する work_mem の倍数。
データの種類 numeric
既定値 1
使用できる値 1-1000
パラメーターのタイプ dynamic
Documentation hash_mem_multiplier

huge_pages

特性 価値
カテゴリ リソース使用量/メモリ
Description 巨大なメモリ ページの使用を有効または無効にします。 この設定は、仮想コア数が 4 未満のサーバーには適用されません。
データの種類 リスト
既定値 try
使用できる値 on,off,try
パラメーターのタイプ 静的
Documentation 大きなページ

Description

巨大なページは、より大きなブロックでメモリを管理できる機能です。 通常、標準の 4 KB ページとは対照的に、最大 2 MB のブロックを管理できます。

巨大なページを使用すると、CPU を効果的にオフロードするパフォーマンス上の利点が得られます。

  • 変換ルックアサイド バッファー (TLB) ミスの減少など、メモリ管理タスクに関連するオーバーヘッドを削減します。
  • メモリ管理に必要な時間を短縮します。

具体的には、PostgreSQL では、共有メモリ領域にのみ巨大なページを使用できます。 共有バッファーには、共有メモリ領域の重要な部分が割り当てられます。

もう 1 つの利点は、巨大なページが共有メモリ領域をディスクにスワップするのを防ぎ、パフォーマンスをさらに安定させるということです。

推奨事項

  • 大量のメモリ リソースを持つサーバーの場合は、巨大なページを無効にしないでください。 巨大なページを無効にすると、パフォーマンスが低下する可能性があります。
  • 巨大なページをサポートしていない小規模なサーバーから始めて、そのサーバーにスケールアップする場合は、シームレスな移行と最適なパフォーマンスを得るために、 huge_pages 設定を TRY に維持します。

Azure 固有の注

4 つ以上の仮想コアを持つサーバーの場合、基になるオペレーティング システムから巨大なページが自動的に割り当てられます。 この機能は、仮想コアが 4 つ未満のサーバーでは使用できません。 shared_buffersの変更など、共有メモリの設定が変更されると、膨大なページの数が自動的に調整されます。

huge_page_size

特性 価値
カテゴリ リソース使用量/メモリ
Description 要求する必要がある巨大なページのサイズです。
データの種類 整数
既定値 0
使用できる値 0
パラメーターのタイプ 読み取り専用
Documentation huge_page_size

logical_decoding_work_mem

特性 価値
カテゴリ リソース使用量/メモリ
Description 論理デコードに使用する最大メモリを設定します。
データの種類 整数
既定値 65536
使用できる値 64-2147483647
パラメーターのタイプ dynamic
Documentation logical_decoding_work_mem (論理デコーディングワークメモリ)

maintenance_work_mem

特性 価値
カテゴリ リソース使用量/メモリ
Description VACUUM、インデックスの作成などのメンテナンス操作に使用する最大メモリを設定します。
データの種類 整数
既定値 サーバーに割り当てられているリソース (仮想コア、RAM、またはディスク領域) によって異なります。
使用できる値 1024-2097151
パラメーターのタイプ dynamic
Documentation maintenance_work_mem

Description

maintenance_work_mem は PostgreSQL の構成パラメーターです。 VACUUM、CREATE INDEX、ALTER TABLEなど、メンテナンス操作に割り当てられるメモリの量が制御されます。 クエリ操作のメモリ割り当てに影響する work_memとは異なり、 maintenance_work_mem はデータベース構造を維持および最適化するタスク用に予約されています。

![注] maintenance_work_mem を過度にアグレッシブな値に設定すると、システムのメモリ不足エラーが定期的に発生する可能性があります。 このパラメーターを変更する前に、サーバーで使用可能なメモリの量と、前に説明したタスクにメモリを割り当てることができる同時実行操作の数を理解することが非常に重要です。

重要なポイント

  • バキューム メモリ キャップ: maintenance_work_memを増やして消滅タプルのクリーンアップを高速化したい場合は、VACUUMには識別子収集に制限があるため、注意が必要です。 このプロセスでは、最大 1 GB のメモリのみを使用できます。
  • 自動バキュームのメモリの分離: autovacuum_work_mem 設定を使用して、自動バキューム操作が個別に使用するメモリを制御できます。 この設定は、 maintenance_work_memのサブセットとして機能します。 他のメンテナンス タスクやデータ定義操作のメモリ割り当てに影響を与えずに、自動バキュームが使用するメモリの量を決定できます。

Azure 固有の注

maintenance_work_mem サーバー パラメーターの既定値は、Azure Database for PostgreSQL フレキシブル サーバーのインスタンスをプロビジョニングするときに、そのコンピューティング用に選んだ製品名に基づいて計算されます。 その後、フレキシブル サーバーをサポートするコンピューティングに対する製品選択が変更された場合、そのインスタンスの maintenance_work_mem サーバー パラメーターの既定値に影響が及ぶことはありません。

インスタンスに割り当てられた製品を変更するたびに、次の数式の値に従って、 maintenance_work_mem パラメーターの値も調整する必要があります。

maintenance_work_mem の値の計算に使用される数式は (long)(82.5 * ln(memoryGiB) + 40) * 1024 です。

前の数式に基づき、プロビジョニングされたメモリ容量に応じてこのサーバー パラメーターに設定される値を次の表に示します。

メモリ サイズ maintenance_work_mem
2 GiB 99,328 KiB
4 GiB 157,696 KiB
8 GiB 216,064 KiB
16 GiB 274,432 KiB
32 GiB 332,800 KiB
48 GiB 367,616 KiB
64 GiB 392,192 KiB
80 GiB 410,624 KiB
128 GiB 450,560 KiB
160 GiB 468,992 KiB
192 GiB 484,352 KiB
256 GiB 508,928 KiB
384 GiB 542,720 KiB
432 GiB 552,960 KiB
672 GiB 590,848 KiB

max_prepared_transactions（最大準備済みトランザクション）

特性 価値
カテゴリ リソース使用量/メモリ
Description 同時に準備されたトランザクションの最大数を設定します。 レプリカ サーバーを実行する場合は、このパラメーターをプライマリ サーバーの値以上に設定する必要があります。
データの種類 整数
既定値 0
使用できる値 0-262143
パラメーターのタイプ 静的
Documentation max_prepared_transactions

max_stack_depth (最大スタック深度)

特性 価値
カテゴリ リソース使用量/メモリ
Description スタックの最大深度を KB 単位で設定します。
データの種類 整数
既定値 2048
使用できる値 2048
パラメーターのタイプ 読み取り専用
Documentation max_stack_depth

min_dynamic_shared_memory

特性 価値
カテゴリ リソース使用量/メモリ
Description 起動時に予約された動的共有メモリの量です。
データの種類 整数
既定値 0
使用できる値 0
パラメーターのタイプ 読み取り専用
Documentation min_dynamic_shared_memory

共有バッファー

特性 価値
カテゴリ リソース使用量/メモリ
Description サーバーによって使用される共有メモリ バッファーの数を設定します。 単位は 8 KB です。 許可される値は、使用可能なメモリの 10% から 75% の範囲内です。
データの種類 整数
既定値 サーバーに割り当てられているリソース (仮想コア、RAM、またはディスク領域) によって異なります。
使用できる値 16-1073741823
パラメーターのタイプ 静的
Documentation shared_buffers

Description

shared_buffers構成パラメーターは、データをバッファリングするために PostgreSQL データベースに割り当てられるシステム メモリの量を決定します。 これは、すべてのデータベース プロセスからアクセスできる一元化されたメモリ プールとして機能します。

データが必要な場合、データベース プロセスは最初に共有バッファーをチェックします。 必要なデータが存在する場合は、すばやく取得され、より時間のかかるディスク読み取りをバイパスします。 共有バッファーは、データベース プロセスとディスク間の仲介役として機能し、必要な I/O 操作の数を効果的に減らします。

Azure 固有の注

shared_buffers サーバー パラメーターの既定値は、Azure Database for PostgreSQL フレキシブル サーバーのインスタンスをプロビジョニングするときに、そのコンピューティング用に選んだ製品名に基づいて計算されます。 フレキシブル サーバーをサポートするコンピューティングに対する製品選択の後続の変更は、そのインスタンスの shared_buffers サーバー パラメーターの既定値には影響しません。

インスタンスに割り当てられた製品を変更するたびに、次の数式の値に従って、 shared_buffers パラメーターの値も調整する必要があります。

最大 2 GiB のメモリを持つ仮想マシンの場合、 shared_buffers の値の計算に使用される数式は memoryGib * 16384。

2 GiB を超える仮想マシンの場合、 shared_buffers の値の計算に使用される数式は memoryGib * 32768。

前の数式に基づき、プロビジョニングされたメモリ容量に応じてこのサーバー パラメーターに設定される値を次の表に示します。

メモリ サイズ 共有バッファー
2 GiB 32768
4 GiB 131072
8 GiB 262144
16 GiB 524288
32 GiB 1048576
48 GiB 1572864
64 GiB 2097152
80 GiB 2621440
128 GiB 4194304
160 GiB 5242880
192 GiB 6291456
256 GiB 8388608
384 GiB 12582912
432 GiB 14155776
672 GiB 22020096

共有メモリタイプ

特性 価値
カテゴリ リソース使用量/メモリ
Description メイン共有メモリ領域に使用される共有メモリ実装を選択します。
データの種類 リスト
既定値 mmap
使用できる値 mmap
パラメーターのタイプ 読み取り専用
Documentation shared_memory_type

テンポラリーバッファー

特性 価値
カテゴリ リソース使用量/メモリ
Description 各データベース セッションで使用される一時バッファーの最大数を設定します。
データの種類 整数
既定値 1024
使用できる値 100-1073741823
パラメーターのタイプ dynamic
Documentation temp_buffers

作業メモリー

特性 価値
カテゴリ リソース使用量/メモリ
Description それを超えると一時ディスク ファイルへの書き込みが行われる、内部並べ替え操作とハッシュ テーブルによって使用されたメモリの量を設定します。
データの種類 整数
既定値 4096
使用できる値 4096-2097151
パラメーターのタイプ dynamic
Documentation work_mem

Description

PostgreSQL の work_mem パラメーターは、各データベース セッションのプライベート メモリ領域内の特定の内部操作に割り当てられるメモリの量を制御します。 これらの操作の例として、並べ替えとハッシュがあります。

共有メモリ領域にある共有バッファーとは異なり、 work_mem はセッションごとまたはクエリごとのプライベート メモリ領域に割り当てられます。 適切な work_mem サイズを設定することで、これらの操作の効率を大幅に向上させ、一時データをディスクに書き込む必要性を減らすことができます。

重要なポイント

  • プライベート接続メモリ: work_mem は、各データベース セッションで使用されるプライベート メモリの一部です。 このメモリは、 shared_buffers が使用する共有メモリ領域とは異なります。
  • クエリ固有の使用方法: すべてのセッションまたはクエリで work_memが使用されるわけではありません。 SELECT 1のような単純なクエリでは、work_memが必要な可能性はほとんどありません。 ただし、並べ替えやハッシュなどの操作を伴う複雑なクエリでは、1 つまたは複数のチャンクの work_memを使用できます。
  • 並列操作: 複数の並列バックエンドにまたがるクエリの場合、各バックエンドが 1 つまたは複数のチャンクの work_memを使用する可能性があります。

work_memの監視と調整

システムのパフォーマンスを継続的に監視し、必要に応じて work_mem を調整することが不可欠です。主に、並べ替えやハッシュ操作に関連するクエリの実行時間が遅い場合です。 Azure portal で使用できるツールを使用してパフォーマンスを監視する方法を次に示します。

細かい調整

work_mem パラメーターの管理中は、多くの場合、グローバル値を設定するのではなく、細かい調整アプローチを採用する方が効率的です。 この方法により、プロセスとユーザーの特定のニーズに基づいてメモリを慎重に割り当てることができます。 また、メモリ不足の問題が発生するリスクも最小限に抑えられます。 その方法を次に示します。

  • ユーザー レベル: 特定のユーザーが主に集計タスクまたはレポート タスクに関与している場合は、そのユーザーの work_mem 値をカスタマイズすることを検討してください。 ALTER ROLE コマンドを使用して、ユーザーの操作のパフォーマンスを向上させます。

  • 関数/プロシージャ レベル: 特定の関数またはプロシージャが大量の一時ファイルを生成している場合は、特定の関数またはプロシージャ レベルで work_mem 値を増やすと役立ちます。 ALTER FUNCTIONまたは ALTER PROCEDURE コマンドを使用して、これらの操作により多くのメモリを割り当てます。

  • データベース レベル: 特定のデータベースのみが多数の一時ファイルを生成している場合は、データベース レベルで work_mem を変更します。

  • グローバル レベル: システムの分析で、ほとんどのクエリで小さな一時ファイルが生成されているのに、大きなファイルが作成されているのはごくわずかである場合、 work_mem 値をグローバルに増やすことが賢明な場合があります。 このアクションにより、ほとんどのクエリでメモリ内の処理が容易になるため、ディスク ベースの操作を回避し、効率を向上させることができます。 ただし、サーバーのメモリ使用率は常に注意して監視し、増加した work_mem 値を確実に処理できるようにします。

並べ替え操作の最小work_mem値の決定

特定のクエリ (特に並べ替え処理中に一時ディスク ファイルを生成するクエリ) の最小 work_mem 値を見つけるには、まず、クエリの実行中に生成される一時ファイル サイズを考慮します。 たとえば、クエリで 20 MB の一時ファイルが生成されている場合は、次のようになります。

  1. psql または任意の PostgreSQL クライアントを使用してデータベースに接続します。
  2. メモリ内での処理時に追加のヘッダーを考慮するために、初期 work_mem 値を 20 MB より少し高く設定します。 SET work_mem TO '25MB'などのコマンドを使用します。
  3. 同じセッションで問題のあるクエリに対して EXPLAIN ANALYZE を実行します。
  4. "Sort Method: quicksort Memory: xkB"の出力を確認します。 "external merge Disk: xkB"を示す場合は、work_mem値を段階的に上げ、"quicksort Memory"が表示されるまで再テストします。 "quicksort Memory"の外観は、クエリがメモリ内で動作していることを示します。
  5. この方法を使用して値を決定したら、運用上のニーズに合わせて、グローバルに、またはより詳細なレベル (前述) に適用できます。

autovacuum_work_mem

特性 価値
カテゴリ リソース使用量/メモリ
Description 各自動バキューム worker プロセスで使用される最大メモリを設定します。
データの種類 整数
既定値 -1
使用できる値 -1-2097151
パラメーターのタイプ dynamic
Documentation autovacuum_work_mem

動的共有メモリータイプ

特性 価値
カテゴリ リソース使用量/メモリ
Description 使用されている動的共有メモリの実装を選択します。
データの種類 リスト
既定値 posix
使用できる値 posix
パラメーターのタイプ 読み取り専用
Documentation dynamic_shared_memory_type

hash_mem_multiplier

特性 価値
カテゴリ リソース使用量/メモリ
Description ハッシュ テーブルに使用する work_mem の倍数。
データの種類 numeric
既定値 1
使用できる値 1-1000
パラメーターのタイプ dynamic
Documentation hash_mem_multiplier

huge_pages

特性 価値
カテゴリ リソース使用量/メモリ
Description 巨大なメモリ ページの使用を有効または無効にします。 この設定は、仮想コア数が 4 未満のサーバーには適用されません。
データの種類 リスト
既定値 try
使用できる値 on,off,try
パラメーターのタイプ 静的
Documentation 大きなページ

Description

巨大なページは、より大きなブロックでメモリを管理できる機能です。 通常、標準の 4 KB ページとは対照的に、最大 2 MB のブロックを管理できます。

巨大なページを使用すると、CPU を効果的にオフロードするパフォーマンス上の利点が得られます。

  • 変換ルックアサイド バッファー (TLB) ミスの減少など、メモリ管理タスクに関連するオーバーヘッドを削減します。
  • メモリ管理に必要な時間を短縮します。

具体的には、PostgreSQL では、共有メモリ領域にのみ巨大なページを使用できます。 共有バッファーには、共有メモリ領域の重要な部分が割り当てられます。

もう 1 つの利点は、巨大なページが共有メモリ領域をディスクにスワップするのを防ぎ、パフォーマンスをさらに安定させるということです。

推奨事項

  • 大量のメモリ リソースを持つサーバーの場合は、巨大なページを無効にしないでください。 巨大なページを無効にすると、パフォーマンスが低下する可能性があります。
  • 巨大なページをサポートしていない小規模なサーバーから始めて、そのサーバーにスケールアップする場合は、シームレスな移行と最適なパフォーマンスを得るために、 huge_pages 設定を TRY に維持します。

Azure 固有の注

4 つ以上の仮想コアを持つサーバーの場合、基になるオペレーティング システムから巨大なページが自動的に割り当てられます。 この機能は、仮想コアが 4 つ未満のサーバーでは使用できません。 shared_buffersの変更など、共有メモリの設定が変更されると、膨大なページの数が自動的に調整されます。

logical_decoding_work_mem

特性 価値
カテゴリ リソース使用量/メモリ
Description 論理デコードに使用する最大メモリを設定します。
データの種類 整数
既定値 65536
使用できる値 64-2147483647
パラメーターのタイプ dynamic
Documentation logical_decoding_work_mem (論理デコーディングワークメモリ)

maintenance_work_mem

特性 価値
カテゴリ リソース使用量/メモリ
Description VACUUM、インデックスの作成などのメンテナンス操作に使用する最大メモリを設定します。
データの種類 整数
既定値 サーバーに割り当てられているリソース (仮想コア、RAM、またはディスク領域) によって異なります。
使用できる値 1024-2097151
パラメーターのタイプ dynamic
Documentation maintenance_work_mem

Description

maintenance_work_mem は PostgreSQL の構成パラメーターです。 VACUUM、CREATE INDEX、ALTER TABLEなど、メンテナンス操作に割り当てられるメモリの量が制御されます。 クエリ操作のメモリ割り当てに影響する work_memとは異なり、 maintenance_work_mem はデータベース構造を維持および最適化するタスク用に予約されています。

![注] maintenance_work_mem を過度にアグレッシブな値に設定すると、システムのメモリ不足エラーが定期的に発生する可能性があります。 このパラメーターを変更する前に、サーバーで使用可能なメモリの量と、前に説明したタスクにメモリを割り当てることができる同時実行操作の数を理解することが非常に重要です。

重要なポイント

  • バキューム メモリ キャップ: maintenance_work_memを増やして消滅タプルのクリーンアップを高速化したい場合は、VACUUMには識別子収集に制限があるため、注意が必要です。 このプロセスでは、最大 1 GB のメモリのみを使用できます。
  • 自動バキュームのメモリの分離: autovacuum_work_mem 設定を使用して、自動バキューム操作が個別に使用するメモリを制御できます。 この設定は、 maintenance_work_memのサブセットとして機能します。 他のメンテナンス タスクやデータ定義操作のメモリ割り当てに影響を与えずに、自動バキュームが使用するメモリの量を決定できます。

Azure 固有の注

maintenance_work_mem サーバー パラメーターの既定値は、Azure Database for PostgreSQL フレキシブル サーバーのインスタンスをプロビジョニングするときに、そのコンピューティング用に選んだ製品名に基づいて計算されます。 その後、フレキシブル サーバーをサポートするコンピューティングに対する製品選択が変更された場合、そのインスタンスの maintenance_work_mem サーバー パラメーターの既定値に影響が及ぶことはありません。

インスタンスに割り当てられた製品を変更するたびに、次の数式の値に従って、 maintenance_work_mem パラメーターの値も調整する必要があります。

maintenance_work_mem の値の計算に使用される数式は (long)(82.5 * ln(memoryGiB) + 40) * 1024 です。

前の数式に基づき、プロビジョニングされたメモリ容量に応じてこのサーバー パラメーターに設定される値を次の表に示します。

メモリ サイズ maintenance_work_mem
2 GiB 99,328 KiB
4 GiB 157,696 KiB
8 GiB 216,064 KiB
16 GiB 274,432 KiB
32 GiB 332,800 KiB
48 GiB 367,616 KiB
64 GiB 392,192 KiB
80 GiB 410,624 KiB
128 GiB 450,560 KiB
160 GiB 468,992 KiB
192 GiB 484,352 KiB
256 GiB 508,928 KiB
384 GiB 542,720 KiB
432 GiB 552,960 KiB
672 GiB 590,848 KiB

max_prepared_transactions（最大準備済みトランザクション）

特性 価値
カテゴリ リソース使用量/メモリ
Description 同時に準備されたトランザクションの最大数を設定します。 レプリカ サーバーを実行する場合は、このパラメーターをプライマリ サーバーの値以上に設定する必要があります。
データの種類 整数
既定値 0
使用できる値 0-262143
パラメーターのタイプ 静的
Documentation max_prepared_transactions

max_stack_depth (最大スタック深度)

特性 価値
カテゴリ リソース使用量/メモリ
Description スタックの最大深度を KB 単位で設定します。
データの種類 整数
既定値 2048
使用できる値 2048
パラメーターのタイプ 読み取り専用
Documentation max_stack_depth

共有バッファー

特性 価値
カテゴリ リソース使用量/メモリ
Description サーバーによって使用される共有メモリ バッファーの数を設定します。 単位は 8 KB です。 許可される値は、使用可能なメモリの 10% から 75% の範囲内です。
データの種類 整数
既定値 サーバーに割り当てられているリソース (仮想コア、RAM、またはディスク領域) によって異なります。
使用できる値 16-1073741823
パラメーターのタイプ 静的
Documentation shared_buffers

Description

shared_buffers構成パラメーターは、データをバッファリングするために PostgreSQL データベースに割り当てられるシステム メモリの量を決定します。 これは、すべてのデータベース プロセスからアクセスできる一元化されたメモリ プールとして機能します。

データが必要な場合、データベース プロセスは最初に共有バッファーをチェックします。 必要なデータが存在する場合は、すばやく取得され、より時間のかかるディスク読み取りをバイパスします。 共有バッファーは、データベース プロセスとディスク間の仲介役として機能し、必要な I/O 操作の数を効果的に減らします。

Azure 固有の注

shared_buffers サーバー パラメーターの既定値は、Azure Database for PostgreSQL フレキシブル サーバーのインスタンスをプロビジョニングするときに、そのコンピューティング用に選んだ製品名に基づいて計算されます。 フレキシブル サーバーをサポートするコンピューティングに対する製品選択の後続の変更は、そのインスタンスの shared_buffers サーバー パラメーターの既定値には影響しません。

インスタンスに割り当てられた製品を変更するたびに、次の数式の値に従って、 shared_buffers パラメーターの値も調整する必要があります。

最大 2 GiB のメモリを持つ仮想マシンの場合、 shared_buffers の値の計算に使用される数式は memoryGib * 16384。

2 GiB を超える仮想マシンの場合、 shared_buffers の値の計算に使用される数式は memoryGib * 32768。

前の数式に基づき、プロビジョニングされたメモリ容量に応じてこのサーバー パラメーターに設定される値を次の表に示します。

メモリ サイズ 共有バッファー
2 GiB 32768
4 GiB 131072
8 GiB 262144
16 GiB 524288
32 GiB 1048576
48 GiB 1572864
64 GiB 2097152
80 GiB 2621440
128 GiB 4194304
160 GiB 5242880
192 GiB 6291456
256 GiB 8388608
384 GiB 12582912
432 GiB 14155776
672 GiB 22020096

共有メモリタイプ

特性 価値
カテゴリ リソース使用量/メモリ
Description メイン共有メモリ領域に使用される共有メモリ実装を選択します。
データの種類 リスト
既定値 mmap
使用できる値 mmap
パラメーターのタイプ 読み取り専用
Documentation shared_memory_type

テンポラリーバッファー

特性 価値
カテゴリ リソース使用量/メモリ
Description 各データベース セッションで使用される一時バッファーの最大数を設定します。
データの種類 整数
既定値 1024
使用できる値 100-1073741823
パラメーターのタイプ dynamic
Documentation temp_buffers

作業メモリー

特性 価値
カテゴリ リソース使用量/メモリ
Description それを超えると一時ディスク ファイルへの書き込みが行われる、内部並べ替え操作とハッシュ テーブルによって使用されたメモリの量を設定します。
データの種類 整数
既定値 4096
使用できる値 4096-2097151
パラメーターのタイプ dynamic
Documentation work_mem

Description

PostgreSQL の work_mem パラメーターは、各データベース セッションのプライベート メモリ領域内の特定の内部操作に割り当てられるメモリの量を制御します。 これらの操作の例として、並べ替えとハッシュがあります。

共有メモリ領域にある共有バッファーとは異なり、 work_mem はセッションごとまたはクエリごとのプライベート メモリ領域に割り当てられます。 適切な work_mem サイズを設定することで、これらの操作の効率を大幅に向上させ、一時データをディスクに書き込む必要性を減らすことができます。

重要なポイント

  • プライベート接続メモリ: work_mem は、各データベース セッションで使用されるプライベート メモリの一部です。 このメモリは、 shared_buffers が使用する共有メモリ領域とは異なります。
  • クエリ固有の使用方法: すべてのセッションまたはクエリで work_memが使用されるわけではありません。 SELECT 1のような単純なクエリでは、work_memが必要な可能性はほとんどありません。 ただし、並べ替えやハッシュなどの操作を伴う複雑なクエリでは、1 つまたは複数のチャンクの work_memを使用できます。
  • 並列操作: 複数の並列バックエンドにまたがるクエリの場合、各バックエンドが 1 つまたは複数のチャンクの work_memを使用する可能性があります。

work_memの監視と調整

システムのパフォーマンスを継続的に監視し、必要に応じて work_mem を調整することが不可欠です。主に、並べ替えやハッシュ操作に関連するクエリの実行時間が遅い場合です。 Azure portal で使用できるツールを使用してパフォーマンスを監視する方法を次に示します。

細かい調整

work_mem パラメーターの管理中は、多くの場合、グローバル値を設定するのではなく、細かい調整アプローチを採用する方が効率的です。 この方法により、プロセスとユーザーの特定のニーズに基づいてメモリを慎重に割り当てることができます。 また、メモリ不足の問題が発生するリスクも最小限に抑えられます。 その方法を次に示します。

  • ユーザー レベル: 特定のユーザーが主に集計タスクまたはレポート タスクに関与している場合は、そのユーザーの work_mem 値をカスタマイズすることを検討してください。 ALTER ROLE コマンドを使用して、ユーザーの操作のパフォーマンスを向上させます。

  • 関数/プロシージャ レベル: 特定の関数またはプロシージャが大量の一時ファイルを生成している場合は、特定の関数またはプロシージャ レベルで work_mem 値を増やすと役立ちます。 ALTER FUNCTIONまたは ALTER PROCEDURE コマンドを使用して、これらの操作により多くのメモリを割り当てます。

  • データベース レベル: 特定のデータベースのみが多数の一時ファイルを生成している場合は、データベース レベルで work_mem を変更します。

  • グローバル レベル: システムの分析で、ほとんどのクエリで小さな一時ファイルが生成されているのに、大きなファイルが作成されているのはごくわずかである場合、 work_mem 値をグローバルに増やすことが賢明な場合があります。 このアクションにより、ほとんどのクエリでメモリ内の処理が容易になるため、ディスク ベースの操作を回避し、効率を向上させることができます。 ただし、サーバーのメモリ使用率は常に注意して監視し、増加した work_mem 値を確実に処理できるようにします。

並べ替え操作の最小work_mem値の決定

特定のクエリ (特に並べ替え処理中に一時ディスク ファイルを生成するクエリ) の最小 work_mem 値を見つけるには、まず、クエリの実行中に生成される一時ファイル サイズを考慮します。 たとえば、クエリで 20 MB の一時ファイルが生成されている場合は、次のようになります。

  1. psql または任意の PostgreSQL クライアントを使用してデータベースに接続します。
  2. メモリ内での処理時に追加のヘッダーを考慮するために、初期 work_mem 値を 20 MB より少し高く設定します。 SET work_mem TO '25MB'などのコマンドを使用します。
  3. 同じセッションで問題のあるクエリに対して EXPLAIN ANALYZE を実行します。
  4. "Sort Method: quicksort Memory: xkB"の出力を確認します。 "external merge Disk: xkB"を示す場合は、work_mem値を段階的に上げ、"quicksort Memory"が表示されるまで再テストします。 "quicksort Memory"の外観は、クエリがメモリ内で動作していることを示します。
  5. この方法を使用して値を決定したら、運用上のニーズに合わせて、グローバルに、またはより詳細なレベル (前述) に適用できます。

autovacuum_work_mem

特性 価値
カテゴリ リソース使用量/メモリ
Description 各自動バキューム worker プロセスで使用される最大メモリを設定します。
データの種類 整数
既定値 -1
使用できる値 -1-2097151
パラメーターのタイプ dynamic
Documentation autovacuum_work_mem

動的共有メモリータイプ

特性 価値
カテゴリ リソース使用量/メモリ
Description 使用されている動的共有メモリの実装を選択します。
データの種類 リスト
既定値 posix
使用できる値 posix
パラメーターのタイプ 読み取り専用
Documentation dynamic_shared_memory_type

hash_mem_multiplier

特性 価値
カテゴリ リソース使用量/メモリ
Description ハッシュ テーブルに使用する work_mem の倍数。
データの種類 numeric
既定値 1
使用できる値 1-1000
パラメーターのタイプ dynamic
Documentation hash_mem_multiplier

huge_pages

特性 価値
カテゴリ リソース使用量/メモリ
Description 巨大なメモリ ページの使用を有効または無効にします。 この設定は、仮想コア数が 4 未満のサーバーには適用されません。
データの種類 リスト
既定値 try
使用できる値 on,off,try
パラメーターのタイプ 静的
Documentation 大きなページ

Description

巨大なページは、より大きなブロックでメモリを管理できる機能です。 通常、標準の 4 KB ページとは対照的に、最大 2 MB のブロックを管理できます。

巨大なページを使用すると、CPU を効果的にオフロードするパフォーマンス上の利点が得られます。

  • 変換ルックアサイド バッファー (TLB) ミスの減少など、メモリ管理タスクに関連するオーバーヘッドを削減します。
  • メモリ管理に必要な時間を短縮します。

具体的には、PostgreSQL では、共有メモリ領域にのみ巨大なページを使用できます。 共有バッファーには、共有メモリ領域の重要な部分が割り当てられます。

もう 1 つの利点は、巨大なページが共有メモリ領域をディスクにスワップするのを防ぎ、パフォーマンスをさらに安定させるということです。

推奨事項

  • 大量のメモリ リソースを持つサーバーの場合は、巨大なページを無効にしないでください。 巨大なページを無効にすると、パフォーマンスが低下する可能性があります。
  • 巨大なページをサポートしていない小規模なサーバーから始めて、そのサーバーにスケールアップする場合は、シームレスな移行と最適なパフォーマンスを得るために、 huge_pages 設定を TRY に維持します。

Azure 固有の注

4 つ以上の仮想コアを持つサーバーの場合、基になるオペレーティング システムから巨大なページが自動的に割り当てられます。 この機能は、仮想コアが 4 つ未満のサーバーでは使用できません。 shared_buffersの変更など、共有メモリの設定が変更されると、膨大なページの数が自動的に調整されます。

maintenance_work_mem

特性 価値
カテゴリ リソース使用量/メモリ
Description VACUUM、インデックスの作成などのメンテナンス操作に使用する最大メモリを設定します。
データの種類 整数
既定値 サーバーに割り当てられているリソース (仮想コア、RAM、またはディスク領域) によって異なります。
使用できる値 1024-2097151
パラメーターのタイプ dynamic
Documentation maintenance_work_mem

Description

maintenance_work_mem は PostgreSQL の構成パラメーターです。 VACUUM、CREATE INDEX、ALTER TABLEなど、メンテナンス操作に割り当てられるメモリの量が制御されます。 クエリ操作のメモリ割り当てに影響する work_memとは異なり、 maintenance_work_mem はデータベース構造を維持および最適化するタスク用に予約されています。

![注] maintenance_work_mem を過度にアグレッシブな値に設定すると、システムのメモリ不足エラーが定期的に発生する可能性があります。 このパラメーターを変更する前に、サーバーで使用可能なメモリの量と、前に説明したタスクにメモリを割り当てることができる同時実行操作の数を理解することが非常に重要です。

重要なポイント

  • バキューム メモリ キャップ: maintenance_work_memを増やして消滅タプルのクリーンアップを高速化したい場合は、VACUUMには識別子収集に制限があるため、注意が必要です。 このプロセスでは、最大 1 GB のメモリのみを使用できます。
  • 自動バキュームのメモリの分離: autovacuum_work_mem 設定を使用して、自動バキューム操作が個別に使用するメモリを制御できます。 この設定は、 maintenance_work_memのサブセットとして機能します。 他のメンテナンス タスクやデータ定義操作のメモリ割り当てに影響を与えずに、自動バキュームが使用するメモリの量を決定できます。

Azure 固有の注

maintenance_work_mem サーバー パラメーターの既定値は、Azure Database for PostgreSQL フレキシブル サーバーのインスタンスをプロビジョニングするときに、そのコンピューティング用に選んだ製品名に基づいて計算されます。 その後、フレキシブル サーバーをサポートするコンピューティングに対する製品選択が変更された場合、そのインスタンスの maintenance_work_mem サーバー パラメーターの既定値に影響が及ぶことはありません。

インスタンスに割り当てられた製品を変更するたびに、次の数式の値に従って、 maintenance_work_mem パラメーターの値も調整する必要があります。

maintenance_work_mem の値の計算に使用される数式は (long)(82.5 * ln(memoryGiB) + 40) * 1024 です。

前の数式に基づき、プロビジョニングされたメモリ容量に応じてこのサーバー パラメーターに設定される値を次の表に示します。

メモリ サイズ maintenance_work_mem
2 GiB 99,328 KiB
4 GiB 157,696 KiB
8 GiB 216,064 KiB
16 GiB 274,432 KiB
32 GiB 332,800 KiB
48 GiB 367,616 KiB
64 GiB 392,192 KiB
80 GiB 410,624 KiB
128 GiB 450,560 KiB
160 GiB 468,992 KiB
192 GiB 484,352 KiB
256 GiB 508,928 KiB
384 GiB 542,720 KiB
432 GiB 552,960 KiB
672 GiB 590,848 KiB

max_prepared_transactions（最大準備済みトランザクション）

特性 価値
カテゴリ リソース使用量/メモリ
Description 同時に準備されたトランザクションの最大数を設定します。 レプリカ サーバーを実行する場合は、このパラメーターをプライマリ サーバーの値以上に設定する必要があります。
データの種類 整数
既定値 0
使用できる値 0-262143
パラメーターのタイプ 静的
Documentation max_prepared_transactions

max_stack_depth (最大スタック深度)

特性 価値
カテゴリ リソース使用量/メモリ
Description スタックの最大深度を KB 単位で設定します。
データの種類 整数
既定値 2048
使用できる値 2048
パラメーターのタイプ 読み取り専用
Documentation max_stack_depth

共有バッファー

特性 価値
カテゴリ リソース使用量/メモリ
Description サーバーによって使用される共有メモリ バッファーの数を設定します。 単位は 8 KB です。 許可される値は、使用可能なメモリの 10% から 75% の範囲内です。
データの種類 整数
既定値 サーバーに割り当てられているリソース (仮想コア、RAM、またはディスク領域) によって異なります。
使用できる値 16-1073741823
パラメーターのタイプ 静的
Documentation shared_buffers

Description

shared_buffers構成パラメーターは、データをバッファリングするために PostgreSQL データベースに割り当てられるシステム メモリの量を決定します。 これは、すべてのデータベース プロセスからアクセスできる一元化されたメモリ プールとして機能します。

データが必要な場合、データベース プロセスは最初に共有バッファーをチェックします。 必要なデータが存在する場合は、すばやく取得され、より時間のかかるディスク読み取りをバイパスします。 共有バッファーは、データベース プロセスとディスク間の仲介役として機能し、必要な I/O 操作の数を効果的に減らします。

Azure 固有の注

shared_buffers サーバー パラメーターの既定値は、Azure Database for PostgreSQL フレキシブル サーバーのインスタンスをプロビジョニングするときに、そのコンピューティング用に選んだ製品名に基づいて計算されます。 フレキシブル サーバーをサポートするコンピューティングに対する製品選択の後続の変更は、そのインスタンスの shared_buffers サーバー パラメーターの既定値には影響しません。

インスタンスに割り当てられた製品を変更するたびに、次の数式の値に従って、 shared_buffers パラメーターの値も調整する必要があります。

最大 2 GiB のメモリを持つ仮想マシンの場合、 shared_buffers の値の計算に使用される数式は memoryGib * 16384。

2 GiB を超える仮想マシンの場合、 shared_buffers の値の計算に使用される数式は memoryGib * 32768。

前の数式に基づき、プロビジョニングされたメモリ容量に応じてこのサーバー パラメーターに設定される値を次の表に示します。

メモリ サイズ 共有バッファー
2 GiB 32768
4 GiB 131072
8 GiB 262144
16 GiB 524288
32 GiB 1048576
48 GiB 1572864
64 GiB 2097152
80 GiB 2621440
128 GiB 4194304
160 GiB 5242880
192 GiB 6291456
256 GiB 8388608
384 GiB 12582912
432 GiB 14155776
672 GiB 22020096

共有メモリタイプ

特性 価値
カテゴリ リソース使用量/メモリ
Description メイン共有メモリ領域に使用される共有メモリ実装を選択します。
データの種類 リスト
既定値 mmap
使用できる値 mmap
パラメーターのタイプ 読み取り専用
Documentation shared_memory_type

テンポラリーバッファー

特性 価値
カテゴリ リソース使用量/メモリ
Description 各データベース セッションで使用される一時バッファーの最大数を設定します。
データの種類 整数
既定値 1024
使用できる値 100-1073741823
パラメーターのタイプ dynamic
Documentation temp_buffers

作業メモリー

特性 価値
カテゴリ リソース使用量/メモリ
Description それを超えると一時ディスク ファイルへの書き込みが行われる、内部並べ替え操作とハッシュ テーブルによって使用されたメモリの量を設定します。
データの種類 整数
既定値 4096
使用できる値 4096-2097151
パラメーターのタイプ dynamic
Documentation work_mem

Description

PostgreSQL の work_mem パラメーターは、各データベース セッションのプライベート メモリ領域内の特定の内部操作に割り当てられるメモリの量を制御します。 これらの操作の例として、並べ替えとハッシュがあります。

共有メモリ領域にある共有バッファーとは異なり、 work_mem はセッションごとまたはクエリごとのプライベート メモリ領域に割り当てられます。 適切な work_mem サイズを設定することで、これらの操作の効率を大幅に向上させ、一時データをディスクに書き込む必要性を減らすことができます。

重要なポイント

  • プライベート接続メモリ: work_mem は、各データベース セッションで使用されるプライベート メモリの一部です。 このメモリは、 shared_buffers が使用する共有メモリ領域とは異なります。
  • クエリ固有の使用方法: すべてのセッションまたはクエリで work_memが使用されるわけではありません。 SELECT 1のような単純なクエリでは、work_memが必要な可能性はほとんどありません。 ただし、並べ替えやハッシュなどの操作を伴う複雑なクエリでは、1 つまたは複数のチャンクの work_memを使用できます。
  • 並列操作: 複数の並列バックエンドにまたがるクエリの場合、各バックエンドが 1 つまたは複数のチャンクの work_memを使用する可能性があります。

work_memの監視と調整

システムのパフォーマンスを継続的に監視し、必要に応じて work_mem を調整することが不可欠です。主に、並べ替えやハッシュ操作に関連するクエリの実行時間が遅い場合です。 Azure portal で使用できるツールを使用してパフォーマンスを監視する方法を次に示します。

細かい調整

work_mem パラメーターの管理中は、多くの場合、グローバル値を設定するのではなく、細かい調整アプローチを採用する方が効率的です。 この方法により、プロセスとユーザーの特定のニーズに基づいてメモリを慎重に割り当てることができます。 また、メモリ不足の問題が発生するリスクも最小限に抑えられます。 その方法を次に示します。

  • ユーザー レベル: 特定のユーザーが主に集計タスクまたはレポート タスクに関与している場合は、そのユーザーの work_mem 値をカスタマイズすることを検討してください。 ALTER ROLE コマンドを使用して、ユーザーの操作のパフォーマンスを向上させます。

  • 関数/プロシージャ レベル: 特定の関数またはプロシージャが大量の一時ファイルを生成している場合は、特定の関数またはプロシージャ レベルで work_mem 値を増やすと役立ちます。 ALTER FUNCTIONまたは ALTER PROCEDURE コマンドを使用して、これらの操作により多くのメモリを割り当てます。

  • データベース レベル: 特定のデータベースのみが多数の一時ファイルを生成している場合は、データベース レベルで work_mem を変更します。

  • グローバル レベル: システムの分析で、ほとんどのクエリで小さな一時ファイルが生成されているのに、大きなファイルが作成されているのはごくわずかである場合、 work_mem 値をグローバルに増やすことが賢明な場合があります。 このアクションにより、ほとんどのクエリでメモリ内の処理が容易になるため、ディスク ベースの操作を回避し、効率を向上させることができます。 ただし、サーバーのメモリ使用率は常に注意して監視し、増加した work_mem 値を確実に処理できるようにします。

並べ替え操作の最小work_mem値の決定

特定のクエリ (特に並べ替え処理中に一時ディスク ファイルを生成するクエリ) の最小 work_mem 値を見つけるには、まず、クエリの実行中に生成される一時ファイル サイズを考慮します。 たとえば、クエリで 20 MB の一時ファイルが生成されている場合は、次のようになります。

  1. psql または任意の PostgreSQL クライアントを使用してデータベースに接続します。
  2. メモリ内での処理時に追加のヘッダーを考慮するために、初期 work_mem 値を 20 MB より少し高く設定します。 SET work_mem TO '25MB'などのコマンドを使用します。
  3. 同じセッションで問題のあるクエリに対して EXPLAIN ANALYZE を実行します。
  4. "Sort Method: quicksort Memory: xkB"の出力を確認します。 "external merge Disk: xkB"を示す場合は、work_mem値を段階的に上げ、"quicksort Memory"が表示されるまで再テストします。 "quicksort Memory"の外観は、クエリがメモリ内で動作していることを示します。
  5. この方法を使用して値を決定したら、運用上のニーズに合わせて、グローバルに、またはより詳細なレベル (前述) に適用できます。

autovacuum_work_mem

特性 価値
カテゴリ リソース使用量/メモリ
Description 各自動バキューム worker プロセスで使用される最大メモリを設定します。
データの種類 整数
既定値 -1
使用できる値 -1-2097151
パラメーターのタイプ dynamic
Documentation autovacuum_work_mem

動的共有メモリータイプ

特性 価値
カテゴリ リソース使用量/メモリ
Description 使用されている動的共有メモリの実装を選択します。
データの種類 リスト
既定値 posix
使用できる値 posix
パラメーターのタイプ 読み取り専用
Documentation dynamic_shared_memory_type

huge_pages

特性 価値
カテゴリ リソース使用量/メモリ
Description 巨大なメモリ ページの使用を有効または無効にします。 この設定は、仮想コア数が 4 未満のサーバーには適用されません。
データの種類 リスト
既定値 try
使用できる値 on,off,try
パラメーターのタイプ 静的
Documentation 大きなページ

Description

巨大なページは、より大きなブロックでメモリを管理できる機能です。 通常、標準の 4 KB ページとは対照的に、最大 2 MB のブロックを管理できます。

巨大なページを使用すると、CPU を効果的にオフロードするパフォーマンス上の利点が得られます。

  • 変換ルックアサイド バッファー (TLB) ミスの減少など、メモリ管理タスクに関連するオーバーヘッドを削減します。
  • メモリ管理に必要な時間を短縮します。

具体的には、PostgreSQL では、共有メモリ領域にのみ巨大なページを使用できます。 共有バッファーには、共有メモリ領域の重要な部分が割り当てられます。

もう 1 つの利点は、巨大なページが共有メモリ領域をディスクにスワップするのを防ぎ、パフォーマンスをさらに安定させるということです。

推奨事項

  • 大量のメモリ リソースを持つサーバーの場合は、巨大なページを無効にしないでください。 巨大なページを無効にすると、パフォーマンスが低下する可能性があります。
  • 巨大なページをサポートしていない小規模なサーバーから始めて、そのサーバーにスケールアップする場合は、シームレスな移行と最適なパフォーマンスを得るために、 huge_pages 設定を TRY に維持します。

Azure 固有の注

4 つ以上の仮想コアを持つサーバーの場合、基になるオペレーティング システムから巨大なページが自動的に割り当てられます。 この機能は、仮想コアが 4 つ未満のサーバーでは使用できません。 shared_buffersの変更など、共有メモリの設定が変更されると、膨大なページの数が自動的に調整されます。

maintenance_work_mem

特性 価値
カテゴリ リソース使用量/メモリ
Description VACUUM、インデックスの作成などのメンテナンス操作に使用する最大メモリを設定します。
データの種類 整数
既定値 サーバーに割り当てられているリソース (仮想コア、RAM、またはディスク領域) によって異なります。
使用できる値 1024-2097151
パラメーターのタイプ dynamic
Documentation maintenance_work_mem

Description

maintenance_work_mem は PostgreSQL の構成パラメーターです。 VACUUM、CREATE INDEX、ALTER TABLEなど、メンテナンス操作に割り当てられるメモリの量が制御されます。 クエリ操作のメモリ割り当てに影響する work_memとは異なり、 maintenance_work_mem はデータベース構造を維持および最適化するタスク用に予約されています。

![注] maintenance_work_mem を過度にアグレッシブな値に設定すると、システムのメモリ不足エラーが定期的に発生する可能性があります。 このパラメーターを変更する前に、サーバーで使用可能なメモリの量と、前に説明したタスクにメモリを割り当てることができる同時実行操作の数を理解することが非常に重要です。

重要なポイント

  • バキューム メモリ キャップ: maintenance_work_memを増やして消滅タプルのクリーンアップを高速化したい場合は、VACUUMには識別子収集に制限があるため、注意が必要です。 このプロセスでは、最大 1 GB のメモリのみを使用できます。
  • 自動バキュームのメモリの分離: autovacuum_work_mem 設定を使用して、自動バキューム操作が個別に使用するメモリを制御できます。 この設定は、 maintenance_work_memのサブセットとして機能します。 他のメンテナンス タスクやデータ定義操作のメモリ割り当てに影響を与えずに、自動バキュームが使用するメモリの量を決定できます。

Azure 固有の注

maintenance_work_mem サーバー パラメーターの既定値は、Azure Database for PostgreSQL フレキシブル サーバーのインスタンスをプロビジョニングするときに、そのコンピューティング用に選んだ製品名に基づいて計算されます。 その後、フレキシブル サーバーをサポートするコンピューティングに対する製品選択が変更された場合、そのインスタンスの maintenance_work_mem サーバー パラメーターの既定値に影響が及ぶことはありません。

インスタンスに割り当てられた製品を変更するたびに、次の数式の値に従って、 maintenance_work_mem パラメーターの値も調整する必要があります。

maintenance_work_mem の値の計算に使用される数式は (long)(82.5 * ln(memoryGiB) + 40) * 1024 です。

前の数式に基づき、プロビジョニングされたメモリ容量に応じてこのサーバー パラメーターに設定される値を次の表に示します。

メモリ サイズ maintenance_work_mem
2 GiB 99,328 KiB
4 GiB 157,696 KiB
8 GiB 216,064 KiB
16 GiB 274,432 KiB
32 GiB 332,800 KiB
48 GiB 367,616 KiB
64 GiB 392,192 KiB
80 GiB 410,624 KiB
128 GiB 450,560 KiB
160 GiB 468,992 KiB
192 GiB 484,352 KiB
256 GiB 508,928 KiB
384 GiB 542,720 KiB
432 GiB 552,960 KiB
672 GiB 590,848 KiB

max_prepared_transactions（最大準備済みトランザクション）

特性 価値
カテゴリ リソース使用量/メモリ
Description 同時に準備されたトランザクションの最大数を設定します。 レプリカ サーバーを実行する場合は、このパラメーターをプライマリ サーバーの値以上に設定する必要があります。
データの種類 整数
既定値 0
使用できる値 0-262143
パラメーターのタイプ 静的
Documentation max_prepared_transactions

max_stack_depth (最大スタック深度)

特性 価値
カテゴリ リソース使用量/メモリ
Description スタックの最大深度を KB 単位で設定します。
データの種類 整数
既定値 2048
使用できる値 2048
パラメーターのタイプ 読み取り専用
Documentation max_stack_depth

共有バッファー

特性 価値
カテゴリ リソース使用量/メモリ
Description サーバーによって使用される共有メモリ バッファーの数を設定します。 単位は 8 KB です。 許可される値は、使用可能なメモリの 10% から 75% の範囲内です。
データの種類 整数
既定値 サーバーに割り当てられているリソース (仮想コア、RAM、またはディスク領域) によって異なります。
使用できる値 16-1073741823
パラメーターのタイプ 静的
Documentation shared_buffers

Description

shared_buffers構成パラメーターは、データをバッファリングするために PostgreSQL データベースに割り当てられるシステム メモリの量を決定します。 これは、すべてのデータベース プロセスからアクセスできる一元化されたメモリ プールとして機能します。

データが必要な場合、データベース プロセスは最初に共有バッファーをチェックします。 必要なデータが存在する場合は、すばやく取得され、より時間のかかるディスク読み取りをバイパスします。 共有バッファーは、データベース プロセスとディスク間の仲介役として機能し、必要な I/O 操作の数を効果的に減らします。

Azure 固有の注

shared_buffers サーバー パラメーターの既定値は、Azure Database for PostgreSQL フレキシブル サーバーのインスタンスをプロビジョニングするときに、そのコンピューティング用に選んだ製品名に基づいて計算されます。 フレキシブル サーバーをサポートするコンピューティングに対する製品選択の後続の変更は、そのインスタンスの shared_buffers サーバー パラメーターの既定値には影響しません。

インスタンスに割り当てられた製品を変更するたびに、次の数式の値に従って、 shared_buffers パラメーターの値も調整する必要があります。

最大 2 GiB のメモリを持つ仮想マシンの場合、 shared_buffers の値の計算に使用される数式は memoryGib * 16384。

2 GiB を超える仮想マシンの場合、 shared_buffers の値の計算に使用される数式は memoryGib * 32768。

前の数式に基づき、プロビジョニングされたメモリ容量に応じてこのサーバー パラメーターに設定される値を次の表に示します。

メモリ サイズ 共有バッファー
2 GiB 32768
4 GiB 131072
8 GiB 262144
16 GiB 524288
32 GiB 1048576
48 GiB 1572864
64 GiB 2097152
80 GiB 2621440
128 GiB 4194304
160 GiB 5242880
192 GiB 6291456
256 GiB 8388608
384 GiB 12582912
432 GiB 14155776
672 GiB 22020096

テンポラリーバッファー

特性 価値
カテゴリ リソース使用量/メモリ
Description 各データベース セッションで使用される一時バッファーの最大数を設定します。
データの種類 整数
既定値 1024
使用できる値 100-1073741823
パラメーターのタイプ dynamic
Documentation temp_buffers

作業メモリー

特性 価値
カテゴリ リソース使用量/メモリ
Description それを超えると一時ディスク ファイルへの書き込みが行われる、内部並べ替え操作とハッシュ テーブルによって使用されたメモリの量を設定します。
データの種類 整数
既定値 4096
使用できる値 4096-2097151
パラメーターのタイプ dynamic
Documentation work_mem

Description

PostgreSQL の work_mem パラメーターは、各データベース セッションのプライベート メモリ領域内の特定の内部操作に割り当てられるメモリの量を制御します。 これらの操作の例として、並べ替えとハッシュがあります。

共有メモリ領域にある共有バッファーとは異なり、 work_mem はセッションごとまたはクエリごとのプライベート メモリ領域に割り当てられます。 適切な work_mem サイズを設定することで、これらの操作の効率を大幅に向上させ、一時データをディスクに書き込む必要性を減らすことができます。

重要なポイント

  • プライベート接続メモリ: work_mem は、各データベース セッションで使用されるプライベート メモリの一部です。 このメモリは、 shared_buffers が使用する共有メモリ領域とは異なります。
  • クエリ固有の使用方法: すべてのセッションまたはクエリで work_memが使用されるわけではありません。 SELECT 1のような単純なクエリでは、work_memが必要な可能性はほとんどありません。 ただし、並べ替えやハッシュなどの操作を伴う複雑なクエリでは、1 つまたは複数のチャンクの work_memを使用できます。
  • 並列操作: 複数の並列バックエンドにまたがるクエリの場合、各バックエンドが 1 つまたは複数のチャンクの work_memを使用する可能性があります。

work_memの監視と調整

システムのパフォーマンスを継続的に監視し、必要に応じて work_mem を調整することが不可欠です。主に、並べ替えやハッシュ操作に関連するクエリの実行時間が遅い場合です。 Azure portal で使用できるツールを使用してパフォーマンスを監視する方法を次に示します。

細かい調整

work_mem パラメーターの管理中は、多くの場合、グローバル値を設定するのではなく、細かい調整アプローチを採用する方が効率的です。 この方法により、プロセスとユーザーの特定のニーズに基づいてメモリを慎重に割り当てることができます。 また、メモリ不足の問題が発生するリスクも最小限に抑えられます。 その方法を次に示します。

  • ユーザー レベル: 特定のユーザーが主に集計タスクまたはレポート タスクに関与している場合は、そのユーザーの work_mem 値をカスタマイズすることを検討してください。 ALTER ROLE コマンドを使用して、ユーザーの操作のパフォーマンスを向上させます。

  • 関数/プロシージャ レベル: 特定の関数またはプロシージャが大量の一時ファイルを生成している場合は、特定の関数またはプロシージャ レベルで work_mem 値を増やすと役立ちます。 ALTER FUNCTIONまたは ALTER PROCEDURE コマンドを使用して、これらの操作により多くのメモリを割り当てます。

  • データベース レベル: 特定のデータベースのみが多数の一時ファイルを生成している場合は、データベース レベルで work_mem を変更します。

  • グローバル レベル: システムの分析で、ほとんどのクエリで小さな一時ファイルが生成されているのに、大きなファイルが作成されているのはごくわずかである場合、 work_mem 値をグローバルに増やすことが賢明な場合があります。 このアクションにより、ほとんどのクエリでメモリ内の処理が容易になるため、ディスク ベースの操作を回避し、効率を向上させることができます。 ただし、サーバーのメモリ使用率は常に注意して監視し、増加した work_mem 値を確実に処理できるようにします。

並べ替え操作の最小work_mem値の決定

特定のクエリ (特に並べ替え処理中に一時ディスク ファイルを生成するクエリ) の最小 work_mem 値を見つけるには、まず、クエリの実行中に生成される一時ファイル サイズを考慮します。 たとえば、クエリで 20 MB の一時ファイルが生成されている場合は、次のようになります。

  1. psql または任意の PostgreSQL クライアントを使用してデータベースに接続します。
  2. メモリ内での処理時に追加のヘッダーを考慮するために、初期 work_mem 値を 20 MB より少し高く設定します。 SET work_mem TO '25MB'などのコマンドを使用します。
  3. 同じセッションで問題のあるクエリに対して EXPLAIN ANALYZE を実行します。
  4. "Sort Method: quicksort Memory: xkB"の出力を確認します。 "external merge Disk: xkB"を示す場合は、work_mem値を段階的に上げ、"quicksort Memory"が表示されるまで再テストします。 "quicksort Memory"の外観は、クエリがメモリ内で動作していることを示します。
  5. この方法を使用して値を決定したら、運用上のニーズに合わせて、グローバルに、またはより詳細なレベル (前述) に適用できます。
  • Last updated on