次の方法で共有


リソース使用量/メモリ

autovacuum_work_mem

属性 Value
カテゴリ リソース使用量/メモリ
説明 各自動バキューム ワーカー プロセスで使用される最大メモリを設定します。
データの種類 integer
既定値 -1
使用できる値 -1-2097151
パラメーターの型 動的
ドキュメント autovacuum_work_mem

dynamic_shared_memory_type

属性 Value
カテゴリ リソース使用量/メモリ
説明 使用されている動的共有メモリの実装を選択します。
データの種類 列挙型
既定値 posix
使用できる値 posix
パラメーターの型 読み取り専用
ドキュメント dynamic_shared_memory_type

hash_mem_multiplier

属性 Value
カテゴリ リソース使用量/メモリ
説明 ハッシュ テーブルに使用する work_mem の倍数。
データの種類 numeric
既定値 2
使用できる値 1-1000
パラメーターの型 動的
ドキュメント hash_mem_multiplier

huge_pages

属性 Value
カテゴリ リソース使用量/メモリ
説明 巨大なメモリ ページの使用を有効または無効にします。 この設定は、仮想コア数が 4 未満のサーバーには適用されません。
データの種類 列挙型
既定値 try
使用できる値 on,off,try
パラメーターの型 static
ドキュメント huge_pages

説明

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

Huge Pages を利用すると、CPU を効果的にオフロードするパフォーマンス上の利点が得られます。

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

具体的には、PostgreSQL では、Huge Pages は共有メモリ領域にのみ使用できます。 共有メモリ領域の大部分は共有バッファーに割り当てられます。

もう 1 つの利点は、Huge Pages では共有メモリ領域のディスクへの入れ替えを防ぎ、パフォーマンスをさらに安定させるということです。

推奨事項

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

Azure 固有の注

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

huge_page_size

属性 Value
カテゴリ リソース使用量/メモリ
説明 要求する必要がある巨大なページのサイズ。
データの種類 integer
既定値 0
使用できる値 0
パラメーターの型 読み取り専用
ドキュメント huge_page_size

logical_decoding_work_mem

属性 Value
カテゴリ リソース使用量/メモリ
説明 論理デコードに使用する最大メモリを設定します。
データの種類 integer
既定値 65536
使用できる値 65536
パラメーターの型 読み取り専用
ドキュメント logical_decoding_work_mem

maintenance_work_mem

属性 Value
カテゴリ リソース使用量/メモリ
説明 VACUUM、インデックスの作成などのメンテナンス操作に使用する最大メモリを設定します。
データの種類 integer
規定値 サーバーに割り当てられているリソース (仮想コア、RAM、またはディスク領域) によって異なります。
使用できる値 1024-2097151
パラメーターの型 動的
ドキュメント maintenance_work_mem

説明

maintenance_work_mem は PostgreSQL の構成パラメーターです。 VACUUMCREATE INDEXALTER TABLE など、メンテナンス操作に割り当てられるメモリの量を管理します。 クエリ操作のメモリ割り当てに影響を与える 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 99328 KiB
4 GiB 157696 KiB
8 GiB 216064 KiB
16 GiB 274432 KiB
32 GiB 332800 KiB
48 GiB 367616 KiB
64 GiB 392192 KiB
80 GiB 410624 KiB
128 GiB 450560 KiB
160 GiB 468992 KiB
192 GiB 484352 KiB
256 GiB 508928 KiB
384 GiB 542720 KiB
432 GiB 552960 KiB
672 GiB 590848 KiB

max_prepared_transactions

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

max_stack_depth

属性 Value
カテゴリ リソース使用量/メモリ
説明 スタックの最大深度を KB 単位で設定します。
データの種類 integer
既定値 2048
使用できる値 2048
パラメーターの型 読み取り専用
ドキュメント max_stack_depth

min_dynamic_shared_memory

属性 Value
カテゴリ リソース使用量/メモリ
説明 起動時に予約された動的共有メモリの量。
データの種類 integer
既定値 0
使用できる値 0
パラメーターの型 読み取り専用
ドキュメント min_dynamic_shared_memory

shared_buffers

属性 Value
カテゴリ リソース使用量/メモリ
説明 サーバーによって使用される共有メモリ バッファーの数を設定します。 単位は 8 KB です。 許可される値は、使用可能なメモリの 10% から 75% の範囲内です。
データの種類 integer
規定値 サーバーに割り当てられているリソース (仮想コア、RAM、またはディスク領域) によって異なります。
使用できる値 16-1073741823
パラメーターの型 static
ドキュメント shared_buffers

説明

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 です。

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

メモリ サイズ shared_buffers
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

shared_memory_type

属性 Value
カテゴリ リソース使用量/メモリ
説明 メイン共有メモリ領域に使用される共有メモリ実装を選択します。
データの種類 列挙型
既定値 mmap
使用できる値 mmap
パラメーターの型 読み取り専用
ドキュメント shared_memory_type

temp_buffers

属性 Value
カテゴリ リソース使用量/メモリ
説明 各データベース セッションで使用される一時バッファーの最大数を設定します。
データの種類 integer
既定値 1024
使用できる値 100-1073741823
パラメーターの型 動的
ドキュメント temp_buffers

vacuum_buffer_usage_limit

属性 Value
カテゴリ リソース使用量/メモリ
説明 VACUUM、ANALYZE、および自動バキュームのバッファー プール サイズを設定します。
データの種類 integer
既定値 2048
使用できる値 0-16777216
パラメーターの型 動的
ドキュメント vacuum_buffer_usage_limit

work_mem

属性 Value
カテゴリ リソース使用量/メモリ
説明 それを超えると一時ディスク ファイルへの書き込みが行われる、内部並べ替え操作とハッシュ テーブルによって使用されたメモリの量を設定します。
データの種類 integer
既定値 4096
使用できる値 4096-2097151
パラメーターの型 動的
ドキュメント work_mem

説明

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

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

重要なポイント

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

work_mem の監視と調整

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

  • クエリ パフォーマンス分析情報: [一時ファイル別の上位クエリ] タブを確認して、一時ファイルを生成しているクエリを特定します。 この状況は、work_mem を増やす必要が生じる可能性があることを示しています。
  • トラブルシューティング ガイド: トラブルシューティング ガイドの [高い一時ファイル数] タブを使用して、問題のあるクエリを特定します。
詳細な調整

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

属性 Value
カテゴリ リソース使用量/メモリ
説明 各自動バキューム ワーカー プロセスで使用される最大メモリを設定します。
データの種類 integer
既定値 -1
使用できる値 -1-2097151
パラメーターの型 動的
ドキュメント autovacuum_work_mem

dynamic_shared_memory_type

属性 Value
カテゴリ リソース使用量/メモリ
説明 使用されている動的共有メモリの実装を選択します。
データの種類 列挙型
既定値 posix
使用できる値 posix
パラメーターの型 読み取り専用
ドキュメント dynamic_shared_memory_type

hash_mem_multiplier

属性 Value
カテゴリ リソース使用量/メモリ
説明 ハッシュ テーブルに使用する work_mem の倍数。
データの種類 numeric
既定値 2
使用できる値 1-1000
パラメーターの型 動的
ドキュメント hash_mem_multiplier

huge_pages

属性 Value
カテゴリ リソース使用量/メモリ
説明 巨大なメモリ ページの使用を有効または無効にします。 この設定は、仮想コア数が 4 未満のサーバーには適用されません。
データの種類 列挙型
既定値 try
使用できる値 on,off,try
パラメーターの型 static
ドキュメント huge_pages

説明

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

Huge Pages を利用すると、CPU を効果的にオフロードするパフォーマンス上の利点が得られます。

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

具体的には、PostgreSQL では、Huge Pages は共有メモリ領域にのみ使用できます。 共有メモリ領域の大部分は共有バッファーに割り当てられます。

もう 1 つの利点は、Huge Pages では共有メモリ領域のディスクへの入れ替えを防ぎ、パフォーマンスをさらに安定させるということです。

推奨事項

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

Azure 固有の注

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

huge_page_size

属性 Value
カテゴリ リソース使用量/メモリ
説明 要求する必要がある巨大なページのサイズ。
データの種類 integer
既定値 0
使用できる値 0
パラメーターの型 読み取り専用
ドキュメント huge_page_size

logical_decoding_work_mem

属性 Value
カテゴリ リソース使用量/メモリ
説明 論理デコードに使用する最大メモリを設定します。
データの種類 integer
既定値 65536
使用できる値 64-2147483647
パラメーターの型 動的
ドキュメント logical_decoding_work_mem

maintenance_work_mem

属性 Value
カテゴリ リソース使用量/メモリ
説明 VACUUM、インデックスの作成などのメンテナンス操作に使用する最大メモリを設定します。
データの種類 integer
規定値 サーバーに割り当てられているリソース (仮想コア、RAM、またはディスク領域) によって異なります。
使用できる値 1024-2097151
パラメーターの型 動的
ドキュメント maintenance_work_mem

説明

maintenance_work_mem は PostgreSQL の構成パラメーターです。 VACUUMCREATE INDEXALTER TABLE など、メンテナンス操作に割り当てられるメモリの量を管理します。 クエリ操作のメモリ割り当てに影響を与える 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 99328 KiB
4 GiB 157696 KiB
8 GiB 216064 KiB
16 GiB 274432 KiB
32 GiB 332800 KiB
48 GiB 367616 KiB
64 GiB 392192 KiB
80 GiB 410624 KiB
128 GiB 450560 KiB
160 GiB 468992 KiB
192 GiB 484352 KiB
256 GiB 508928 KiB
384 GiB 542720 KiB
432 GiB 552960 KiB
672 GiB 590848 KiB

max_prepared_transactions

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

max_stack_depth

属性 Value
カテゴリ リソース使用量/メモリ
説明 スタックの最大深度を KB 単位で設定します。
データの種類 integer
既定値 2048
使用できる値 2048
パラメーターの型 読み取り専用
ドキュメント max_stack_depth

min_dynamic_shared_memory

属性 Value
カテゴリ リソース使用量/メモリ
説明 起動時に予約された動的共有メモリの量。
データの種類 integer
既定値 0
使用できる値 0
パラメーターの型 読み取り専用
ドキュメント min_dynamic_shared_memory

shared_buffers

属性 Value
カテゴリ リソース使用量/メモリ
説明 サーバーによって使用される共有メモリ バッファーの数を設定します。 単位は 8 KB です。 許可される値は、使用可能なメモリの 10% から 75% の範囲内です。
データの種類 integer
規定値 サーバーに割り当てられているリソース (仮想コア、RAM、またはディスク領域) によって異なります。
使用できる値 16-1073741823
パラメーターの型 static
ドキュメント shared_buffers

説明

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 です。

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

メモリ サイズ shared_buffers
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

shared_memory_type

属性 Value
カテゴリ リソース使用量/メモリ
説明 メイン共有メモリ領域に使用される共有メモリ実装を選択します。
データの種類 列挙型
既定値 mmap
使用できる値 mmap
パラメーターの型 読み取り専用
ドキュメント shared_memory_type

temp_buffers

属性 Value
カテゴリ リソース使用量/メモリ
説明 各データベース セッションで使用される一時バッファーの最大数を設定します。
データの種類 integer
既定値 1024
使用できる値 100-1073741823
パラメーターの型 動的
ドキュメント temp_buffers

vacuum_buffer_usage_limit

属性 Value
カテゴリ リソース使用量/メモリ
説明 VACUUM、ANALYZE、および自動バキュームのバッファー プール サイズを設定します。
データの種類 integer
既定値 256
使用できる値 0-16777216
パラメーターの型 動的
ドキュメント vacuum_buffer_usage_limit

work_mem

属性 Value
カテゴリ リソース使用量/メモリ
説明 それを超えると一時ディスク ファイルへの書き込みが行われる、内部並べ替え操作とハッシュ テーブルによって使用されたメモリの量を設定します。
データの種類 integer
既定値 4096
使用できる値 4096-2097151
パラメーターの型 動的
ドキュメント work_mem

説明

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

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

重要なポイント

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

work_mem の監視と調整

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

  • クエリ パフォーマンス分析情報: [一時ファイル別の上位クエリ] タブを確認して、一時ファイルを生成しているクエリを特定します。 この状況は、work_mem を増やす必要が生じる可能性があることを示しています。
  • トラブルシューティング ガイド: トラブルシューティング ガイドの [高い一時ファイル数] タブを使用して、問題のあるクエリを特定します。
詳細な調整

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

属性 Value
カテゴリ リソース使用量/メモリ
説明 各自動バキューム ワーカー プロセスで使用される最大メモリを設定します。
データの種類 integer
既定値 -1
使用できる値 -1-2097151
パラメーターの型 動的
ドキュメント autovacuum_work_mem

dynamic_shared_memory_type

属性 Value
カテゴリ リソース使用量/メモリ
説明 使用されている動的共有メモリの実装を選択します。
データの種類 列挙型
既定値 posix
使用できる値 posix
パラメーターの型 読み取り専用
ドキュメント dynamic_shared_memory_type

hash_mem_multiplier

属性 Value
カテゴリ リソース使用量/メモリ
説明 ハッシュ テーブルに使用する work_mem の倍数。
データの種類 numeric
既定値 2
使用できる値 1-1000
パラメーターの型 動的
ドキュメント hash_mem_multiplier

huge_pages

属性 Value
カテゴリ リソース使用量/メモリ
説明 巨大なメモリ ページの使用を有効または無効にします。 この設定は、仮想コア数が 4 未満のサーバーには適用されません。
データの種類 列挙型
既定値 try
使用できる値 on,off,try
パラメーターの型 static
ドキュメント huge_pages

説明

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

Huge Pages を利用すると、CPU を効果的にオフロードするパフォーマンス上の利点が得られます。

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

具体的には、PostgreSQL では、Huge Pages は共有メモリ領域にのみ使用できます。 共有メモリ領域の大部分は共有バッファーに割り当てられます。

もう 1 つの利点は、Huge Pages では共有メモリ領域のディスクへの入れ替えを防ぎ、パフォーマンスをさらに安定させるということです。

推奨事項

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

Azure 固有の注

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

huge_page_size

属性 Value
カテゴリ リソース使用量/メモリ
説明 要求する必要がある巨大なページのサイズ。
データの種類 integer
既定値 0
使用できる値 0
パラメーターの型 読み取り専用
ドキュメント huge_page_size

logical_decoding_work_mem

属性 Value
カテゴリ リソース使用量/メモリ
説明 論理デコードに使用する最大メモリを設定します。
データの種類 integer
既定値 65536
使用できる値 64-2147483647
パラメーターの型 動的
ドキュメント logical_decoding_work_mem

maintenance_work_mem

属性 Value
カテゴリ リソース使用量/メモリ
説明 VACUUM、インデックスの作成などのメンテナンス操作に使用する最大メモリを設定します。
データの種類 integer
規定値 サーバーに割り当てられているリソース (仮想コア、RAM、またはディスク領域) によって異なります。
使用できる値 1024-2097151
パラメーターの型 動的
ドキュメント maintenance_work_mem

説明

maintenance_work_mem は PostgreSQL の構成パラメーターです。 VACUUMCREATE INDEXALTER TABLE など、メンテナンス操作に割り当てられるメモリの量を管理します。 クエリ操作のメモリ割り当てに影響を与える 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 99328 KiB
4 GiB 157696 KiB
8 GiB 216064 KiB
16 GiB 274432 KiB
32 GiB 332800 KiB
48 GiB 367616 KiB
64 GiB 392192 KiB
80 GiB 410624 KiB
128 GiB 450560 KiB
160 GiB 468992 KiB
192 GiB 484352 KiB
256 GiB 508928 KiB
384 GiB 542720 KiB
432 GiB 552960 KiB
672 GiB 590848 KiB

max_prepared_transactions

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

max_stack_depth

属性 Value
カテゴリ リソース使用量/メモリ
説明 スタックの最大深度を KB 単位で設定します。
データの種類 integer
既定値 2048
使用できる値 2048
パラメーターの型 読み取り専用
ドキュメント max_stack_depth

min_dynamic_shared_memory

属性 Value
カテゴリ リソース使用量/メモリ
説明 起動時に予約された動的共有メモリの量。
データの種類 integer
既定値 0
使用できる値 0
パラメーターの型 読み取り専用
ドキュメント min_dynamic_shared_memory

shared_buffers

属性 Value
カテゴリ リソース使用量/メモリ
説明 サーバーによって使用される共有メモリ バッファーの数を設定します。 単位は 8 KB です。 許可される値は、使用可能なメモリの 10% から 75% の範囲内です。
データの種類 integer
規定値 サーバーに割り当てられているリソース (仮想コア、RAM、またはディスク領域) によって異なります。
使用できる値 16-1073741823
パラメーターの型 static
ドキュメント shared_buffers

説明

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 です。

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

メモリ サイズ shared_buffers
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

shared_memory_type

属性 Value
カテゴリ リソース使用量/メモリ
説明 メイン共有メモリ領域に使用される共有メモリ実装を選択します。
データの種類 列挙型
既定値 mmap
使用できる値 mmap
パラメーターの型 読み取り専用
ドキュメント shared_memory_type

temp_buffers

属性 Value
カテゴリ リソース使用量/メモリ
説明 各データベース セッションで使用される一時バッファーの最大数を設定します。
データの種類 integer
既定値 1024
使用できる値 100-1073741823
パラメーターの型 動的
ドキュメント temp_buffers

work_mem

属性 Value
カテゴリ リソース使用量/メモリ
説明 それを超えると一時ディスク ファイルへの書き込みが行われる、内部並べ替え操作とハッシュ テーブルによって使用されたメモリの量を設定します。
データの種類 integer
既定値 4096
使用できる値 4096-2097151
パラメーターの型 動的
ドキュメント work_mem

説明

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

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

重要なポイント

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

work_mem の監視と調整

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

  • クエリ パフォーマンス分析情報: [一時ファイル別の上位クエリ] タブを確認して、一時ファイルを生成しているクエリを特定します。 この状況は、work_mem を増やす必要が生じる可能性があることを示しています。
  • トラブルシューティング ガイド: トラブルシューティング ガイドの [高い一時ファイル数] タブを使用して、問題のあるクエリを特定します。
詳細な調整

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

属性 Value
カテゴリ リソース使用量/メモリ
説明 各自動バキューム ワーカー プロセスで使用される最大メモリを設定します。
データの種類 integer
既定値 -1
使用できる値 -1-2097151
パラメーターの型 動的
ドキュメント autovacuum_work_mem

dynamic_shared_memory_type

属性 Value
カテゴリ リソース使用量/メモリ
説明 使用されている動的共有メモリの実装を選択します。
データの種類 列挙型
既定値 posix
使用できる値 posix
パラメーターの型 読み取り専用
ドキュメント dynamic_shared_memory_type

hash_mem_multiplier

属性 Value
カテゴリ リソース使用量/メモリ
説明 ハッシュ テーブルに使用する work_mem の倍数。
データの種類 numeric
既定値 1
使用できる値 1-1000
パラメーターの型 動的
ドキュメント hash_mem_multiplier

huge_pages

属性 Value
カテゴリ リソース使用量/メモリ
説明 巨大なメモリ ページの使用を有効または無効にします。 この設定は、仮想コア数が 4 未満のサーバーには適用されません。
データの種類 列挙型
既定値 try
使用できる値 on,off,try
パラメーターの型 static
ドキュメント huge_pages

説明

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

Huge Pages を利用すると、CPU を効果的にオフロードするパフォーマンス上の利点が得られます。

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

具体的には、PostgreSQL では、Huge Pages は共有メモリ領域にのみ使用できます。 共有メモリ領域の大部分は共有バッファーに割り当てられます。

もう 1 つの利点は、Huge Pages では共有メモリ領域のディスクへの入れ替えを防ぎ、パフォーマンスをさらに安定させるということです。

推奨事項

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

Azure 固有の注

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

huge_page_size

属性 Value
カテゴリ リソース使用量/メモリ
説明 要求する必要がある巨大なページのサイズ。
データの種類 integer
既定値 0
使用できる値 0
パラメーターの型 読み取り専用
ドキュメント huge_page_size

logical_decoding_work_mem

属性 Value
カテゴリ リソース使用量/メモリ
説明 論理デコードに使用する最大メモリを設定します。
データの種類 integer
既定値 65536
使用できる値 64-2147483647
パラメーターの型 動的
ドキュメント logical_decoding_work_mem

maintenance_work_mem

属性 Value
カテゴリ リソース使用量/メモリ
説明 VACUUM、インデックスの作成などのメンテナンス操作に使用する最大メモリを設定します。
データの種類 integer
規定値 サーバーに割り当てられているリソース (仮想コア、RAM、またはディスク領域) によって異なります。
使用できる値 1024-2097151
パラメーターの型 動的
ドキュメント maintenance_work_mem

説明

maintenance_work_mem は PostgreSQL の構成パラメーターです。 VACUUMCREATE INDEXALTER TABLE など、メンテナンス操作に割り当てられるメモリの量を管理します。 クエリ操作のメモリ割り当てに影響を与える 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 99328 KiB
4 GiB 157696 KiB
8 GiB 216064 KiB
16 GiB 274432 KiB
32 GiB 332800 KiB
48 GiB 367616 KiB
64 GiB 392192 KiB
80 GiB 410624 KiB
128 GiB 450560 KiB
160 GiB 468992 KiB
192 GiB 484352 KiB
256 GiB 508928 KiB
384 GiB 542720 KiB
432 GiB 552960 KiB
672 GiB 590848 KiB

max_prepared_transactions

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

max_stack_depth

属性 Value
カテゴリ リソース使用量/メモリ
説明 スタックの最大深度を KB 単位で設定します。
データの種類 integer
既定値 2048
使用できる値 2048
パラメーターの型 読み取り専用
ドキュメント max_stack_depth

min_dynamic_shared_memory

属性 Value
カテゴリ リソース使用量/メモリ
説明 起動時に予約された動的共有メモリの量。
データの種類 integer
既定値 0
使用できる値 0
パラメーターの型 読み取り専用
ドキュメント min_dynamic_shared_memory

shared_buffers

属性 Value
カテゴリ リソース使用量/メモリ
説明 サーバーによって使用される共有メモリ バッファーの数を設定します。 単位は 8 KB です。 許可される値は、使用可能なメモリの 10% から 75% の範囲内です。
データの種類 integer
規定値 サーバーに割り当てられているリソース (仮想コア、RAM、またはディスク領域) によって異なります。
使用できる値 16-1073741823
パラメーターの型 static
ドキュメント shared_buffers

説明

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 です。

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

メモリ サイズ shared_buffers
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

shared_memory_type

属性 Value
カテゴリ リソース使用量/メモリ
説明 メイン共有メモリ領域に使用される共有メモリ実装を選択します。
データの種類 列挙型
既定値 mmap
使用できる値 mmap
パラメーターの型 読み取り専用
ドキュメント shared_memory_type

temp_buffers

属性 Value
カテゴリ リソース使用量/メモリ
説明 各データベース セッションで使用される一時バッファーの最大数を設定します。
データの種類 integer
既定値 1024
使用できる値 100-1073741823
パラメーターの型 動的
ドキュメント temp_buffers

work_mem

属性 Value
カテゴリ リソース使用量/メモリ
説明 それを超えると一時ディスク ファイルへの書き込みが行われる、内部並べ替え操作とハッシュ テーブルによって使用されたメモリの量を設定します。
データの種類 integer
既定値 4096
使用できる値 4096-2097151
パラメーターの型 動的
ドキュメント work_mem

説明

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

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

重要なポイント

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

work_mem の監視と調整

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

  • クエリ パフォーマンス分析情報: [一時ファイル別の上位クエリ] タブを確認して、一時ファイルを生成しているクエリを特定します。 この状況は、work_mem を増やす必要が生じる可能性があることを示しています。
  • トラブルシューティング ガイド: トラブルシューティング ガイドの [高い一時ファイル数] タブを使用して、問題のあるクエリを特定します。
詳細な調整

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

属性 Value
カテゴリ リソース使用量/メモリ
説明 各自動バキューム ワーカー プロセスで使用される最大メモリを設定します。
データの種類 integer
既定値 -1
使用できる値 -1-2097151
パラメーターの型 動的
ドキュメント autovacuum_work_mem

dynamic_shared_memory_type

属性 Value
カテゴリ リソース使用量/メモリ
説明 使用されている動的共有メモリの実装を選択します。
データの種類 列挙型
既定値 posix
使用できる値 posix
パラメーターの型 読み取り専用
ドキュメント dynamic_shared_memory_type

hash_mem_multiplier

属性 Value
カテゴリ リソース使用量/メモリ
説明 ハッシュ テーブルに使用する work_mem の倍数。
データの種類 numeric
既定値 1
使用できる値 1-1000
パラメーターの型 動的
ドキュメント hash_mem_multiplier

huge_pages

属性 Value
カテゴリ リソース使用量/メモリ
説明 巨大なメモリ ページの使用を有効または無効にします。 この設定は、仮想コア数が 4 未満のサーバーには適用されません。
データの種類 列挙型
既定値 try
使用できる値 on,off,try
パラメーターの型 static
ドキュメント huge_pages

説明

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

Huge Pages を利用すると、CPU を効果的にオフロードするパフォーマンス上の利点が得られます。

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

具体的には、PostgreSQL では、Huge Pages は共有メモリ領域にのみ使用できます。 共有メモリ領域の大部分は共有バッファーに割り当てられます。

もう 1 つの利点は、Huge Pages では共有メモリ領域のディスクへの入れ替えを防ぎ、パフォーマンスをさらに安定させるということです。

推奨事項

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

Azure 固有の注

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

logical_decoding_work_mem

属性 Value
カテゴリ リソース使用量/メモリ
説明 論理デコードに使用する最大メモリを設定します。
データの種類 integer
既定値 65536
使用できる値 64-2147483647
パラメーターの型 動的
ドキュメント logical_decoding_work_mem

maintenance_work_mem

属性 Value
カテゴリ リソース使用量/メモリ
説明 VACUUM、インデックスの作成などのメンテナンス操作に使用する最大メモリを設定します。
データの種類 integer
規定値 サーバーに割り当てられているリソース (仮想コア、RAM、またはディスク領域) によって異なります。
使用できる値 1024-2097151
パラメーターの型 動的
ドキュメント maintenance_work_mem

説明

maintenance_work_mem は PostgreSQL の構成パラメーターです。 VACUUMCREATE INDEXALTER TABLE など、メンテナンス操作に割り当てられるメモリの量を管理します。 クエリ操作のメモリ割り当てに影響を与える 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 99328 KiB
4 GiB 157696 KiB
8 GiB 216064 KiB
16 GiB 274432 KiB
32 GiB 332800 KiB
48 GiB 367616 KiB
64 GiB 392192 KiB
80 GiB 410624 KiB
128 GiB 450560 KiB
160 GiB 468992 KiB
192 GiB 484352 KiB
256 GiB 508928 KiB
384 GiB 542720 KiB
432 GiB 552960 KiB
672 GiB 590848 KiB

max_prepared_transactions

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

max_stack_depth

属性 Value
カテゴリ リソース使用量/メモリ
説明 スタックの最大深度を KB 単位で設定します。
データの種類 integer
既定値 2048
使用できる値 2048
パラメーターの型 読み取り専用
ドキュメント max_stack_depth

shared_buffers

属性 Value
カテゴリ リソース使用量/メモリ
説明 サーバーによって使用される共有メモリ バッファーの数を設定します。 単位は 8 KB です。 許可される値は、使用可能なメモリの 10% から 75% の範囲内です。
データの種類 integer
規定値 サーバーに割り当てられているリソース (仮想コア、RAM、またはディスク領域) によって異なります。
使用できる値 16-1073741823
パラメーターの型 static
ドキュメント shared_buffers

説明

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 です。

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

メモリ サイズ shared_buffers
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

shared_memory_type

属性 Value
カテゴリ リソース使用量/メモリ
説明 メイン共有メモリ領域に使用される共有メモリ実装を選択します。
データの種類 列挙型
既定値 mmap
使用できる値 mmap
パラメーターの型 読み取り専用
ドキュメント shared_memory_type

temp_buffers

属性 Value
カテゴリ リソース使用量/メモリ
説明 各データベース セッションで使用される一時バッファーの最大数を設定します。
データの種類 integer
既定値 1024
使用できる値 100-1073741823
パラメーターの型 動的
ドキュメント temp_buffers

work_mem

属性 Value
カテゴリ リソース使用量/メモリ
説明 それを超えると一時ディスク ファイルへの書き込みが行われる、内部並べ替え操作とハッシュ テーブルによって使用されたメモリの量を設定します。
データの種類 integer
既定値 4096
使用できる値 4096-2097151
パラメーターの型 動的
ドキュメント work_mem

説明

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

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

重要なポイント

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

work_mem の監視と調整

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

  • クエリ パフォーマンス分析情報: [一時ファイル別の上位クエリ] タブを確認して、一時ファイルを生成しているクエリを特定します。 この状況は、work_mem を増やす必要が生じる可能性があることを示しています。
  • トラブルシューティング ガイド: トラブルシューティング ガイドの [高い一時ファイル数] タブを使用して、問題のあるクエリを特定します。
詳細な調整

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

属性 Value
カテゴリ リソース使用量/メモリ
説明 各自動バキューム ワーカー プロセスで使用される最大メモリを設定します。
データの種類 integer
既定値 -1
使用できる値 -1-2097151
パラメーターの型 動的
ドキュメント autovacuum_work_mem

dynamic_shared_memory_type

属性 Value
カテゴリ リソース使用量/メモリ
説明 使用されている動的共有メモリの実装を選択します。
データの種類 列挙型
既定値 posix
使用できる値 posix
パラメーターの型 読み取り専用
ドキュメント dynamic_shared_memory_type

hash_mem_multiplier

属性 Value
カテゴリ リソース使用量/メモリ
説明 ハッシュ テーブルに使用する work_mem の倍数。
データの種類 numeric
既定値 1
使用できる値 1-1000
パラメーターの型 動的
ドキュメント hash_mem_multiplier

huge_pages

属性 Value
カテゴリ リソース使用量/メモリ
説明 巨大なメモリ ページの使用を有効または無効にします。 この設定は、仮想コア数が 4 未満のサーバーには適用されません。
データの種類 列挙型
既定値 try
使用できる値 on,off,try
パラメーターの型 static
ドキュメント huge_pages

説明

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

Huge Pages を利用すると、CPU を効果的にオフロードするパフォーマンス上の利点が得られます。

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

具体的には、PostgreSQL では、Huge Pages は共有メモリ領域にのみ使用できます。 共有メモリ領域の大部分は共有バッファーに割り当てられます。

もう 1 つの利点は、Huge Pages では共有メモリ領域のディスクへの入れ替えを防ぎ、パフォーマンスをさらに安定させるということです。

推奨事項

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

Azure 固有の注

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

maintenance_work_mem

属性 Value
カテゴリ リソース使用量/メモリ
説明 VACUUM、インデックスの作成などのメンテナンス操作に使用する最大メモリを設定します。
データの種類 integer
規定値 サーバーに割り当てられているリソース (仮想コア、RAM、またはディスク領域) によって異なります。
使用できる値 1024-2097151
パラメーターの型 動的
ドキュメント maintenance_work_mem

説明

maintenance_work_mem は PostgreSQL の構成パラメーターです。 VACUUMCREATE INDEXALTER TABLE など、メンテナンス操作に割り当てられるメモリの量を管理します。 クエリ操作のメモリ割り当てに影響を与える 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 99328 KiB
4 GiB 157696 KiB
8 GiB 216064 KiB
16 GiB 274432 KiB
32 GiB 332800 KiB
48 GiB 367616 KiB
64 GiB 392192 KiB
80 GiB 410624 KiB
128 GiB 450560 KiB
160 GiB 468992 KiB
192 GiB 484352 KiB
256 GiB 508928 KiB
384 GiB 542720 KiB
432 GiB 552960 KiB
672 GiB 590848 KiB

max_prepared_transactions

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

max_stack_depth

属性 Value
カテゴリ リソース使用量/メモリ
説明 スタックの最大深度を KB 単位で設定します。
データの種類 integer
既定値 2048
使用できる値 2048
パラメーターの型 読み取り専用
ドキュメント max_stack_depth

shared_buffers

属性 Value
カテゴリ リソース使用量/メモリ
説明 サーバーによって使用される共有メモリ バッファーの数を設定します。 単位は 8 KB です。 許可される値は、使用可能なメモリの 10% から 75% の範囲内です。
データの種類 integer
規定値 サーバーに割り当てられているリソース (仮想コア、RAM、またはディスク領域) によって異なります。
使用できる値 16-1073741823
パラメーターの型 static
ドキュメント shared_buffers

説明

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 です。

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

メモリ サイズ shared_buffers
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

shared_memory_type

属性 Value
カテゴリ リソース使用量/メモリ
説明 メイン共有メモリ領域に使用される共有メモリ実装を選択します。
データの種類 列挙型
既定値 mmap
使用できる値 mmap
パラメーターの型 読み取り専用
ドキュメント shared_memory_type

temp_buffers

属性 Value
カテゴリ リソース使用量/メモリ
説明 各データベース セッションで使用される一時バッファーの最大数を設定します。
データの種類 integer
既定値 1024
使用できる値 100-1073741823
パラメーターの型 動的
ドキュメント temp_buffers

work_mem

属性 Value
カテゴリ リソース使用量/メモリ
説明 それを超えると一時ディスク ファイルへの書き込みが行われる、内部並べ替え操作とハッシュ テーブルによって使用されたメモリの量を設定します。
データの種類 integer
既定値 4096
使用できる値 4096-2097151
パラメーターの型 動的
ドキュメント work_mem

説明

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

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

重要なポイント

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

work_mem の監視と調整

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

  • クエリ パフォーマンス分析情報: [一時ファイル別の上位クエリ] タブを確認して、一時ファイルを生成しているクエリを特定します。 この状況は、work_mem を増やす必要が生じる可能性があることを示しています。
  • トラブルシューティング ガイド: トラブルシューティング ガイドの [高い一時ファイル数] タブを使用して、問題のあるクエリを特定します。
詳細な調整

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

属性 Value
カテゴリ リソース使用量/メモリ
説明 各自動バキューム ワーカー プロセスで使用される最大メモリを設定します。
データの種類 integer
既定値 -1
使用できる値 -1-2097151
パラメーターの型 動的
ドキュメント autovacuum_work_mem

dynamic_shared_memory_type

属性 Value
カテゴリ リソース使用量/メモリ
説明 使用されている動的共有メモリの実装を選択します。
データの種類 列挙型
既定値 posix
使用できる値 posix
パラメーターの型 読み取り専用
ドキュメント dynamic_shared_memory_type

huge_pages

属性 Value
カテゴリ リソース使用量/メモリ
説明 巨大なメモリ ページの使用を有効または無効にします。 この設定は、仮想コア数が 4 未満のサーバーには適用されません。
データの種類 列挙型
既定値 try
使用できる値 on,off,try
パラメーターの型 static
ドキュメント huge_pages

説明

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

Huge Pages を利用すると、CPU を効果的にオフロードするパフォーマンス上の利点が得られます。

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

具体的には、PostgreSQL では、Huge Pages は共有メモリ領域にのみ使用できます。 共有メモリ領域の大部分は共有バッファーに割り当てられます。

もう 1 つの利点は、Huge Pages では共有メモリ領域のディスクへの入れ替えを防ぎ、パフォーマンスをさらに安定させるということです。

推奨事項

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

Azure 固有の注

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

maintenance_work_mem

属性 Value
カテゴリ リソース使用量/メモリ
説明 VACUUM、インデックスの作成などのメンテナンス操作に使用する最大メモリを設定します。
データの種類 integer
規定値 サーバーに割り当てられているリソース (仮想コア、RAM、またはディスク領域) によって異なります。
使用できる値 1024-2097151
パラメーターの型 動的
ドキュメント maintenance_work_mem

説明

maintenance_work_mem は PostgreSQL の構成パラメーターです。 VACUUMCREATE INDEXALTER TABLE など、メンテナンス操作に割り当てられるメモリの量を管理します。 クエリ操作のメモリ割り当てに影響を与える 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 99328 KiB
4 GiB 157696 KiB
8 GiB 216064 KiB
16 GiB 274432 KiB
32 GiB 332800 KiB
48 GiB 367616 KiB
64 GiB 392192 KiB
80 GiB 410624 KiB
128 GiB 450560 KiB
160 GiB 468992 KiB
192 GiB 484352 KiB
256 GiB 508928 KiB
384 GiB 542720 KiB
432 GiB 552960 KiB
672 GiB 590848 KiB

max_prepared_transactions

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

max_stack_depth

属性 Value
カテゴリ リソース使用量/メモリ
説明 スタックの最大深度を KB 単位で設定します。
データの種類 integer
既定値 2048
使用できる値 2048
パラメーターの型 読み取り専用
ドキュメント max_stack_depth

shared_buffers

属性 Value
カテゴリ リソース使用量/メモリ
説明 サーバーによって使用される共有メモリ バッファーの数を設定します。 単位は 8 KB です。 許可される値は、使用可能なメモリの 10% から 75% の範囲内です。
データの種類 integer
規定値 サーバーに割り当てられているリソース (仮想コア、RAM、またはディスク領域) によって異なります。
使用できる値 16-1073741823
パラメーターの型 static
ドキュメント shared_buffers

説明

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 です。

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

メモリ サイズ shared_buffers
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

temp_buffers

属性 Value
カテゴリ リソース使用量/メモリ
説明 各データベース セッションで使用される一時バッファーの最大数を設定します。
データの種類 integer
既定値 1024
使用できる値 100-1073741823
パラメーターの型 動的
ドキュメント temp_buffers

work_mem

属性 Value
カテゴリ リソース使用量/メモリ
説明 それを超えると一時ディスク ファイルへの書き込みが行われる、内部並べ替え操作とハッシュ テーブルによって使用されたメモリの量を設定します。
データの種類 integer
既定値 4096
使用できる値 4096-2097151
パラメーターの型 動的
ドキュメント work_mem

説明

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

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

重要なポイント

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

work_mem の監視と調整

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

  • クエリ パフォーマンス分析情報: [一時ファイル別の上位クエリ] タブを確認して、一時ファイルを生成しているクエリを特定します。 この状況は、work_mem を増やす必要が生じる可能性があることを示しています。
  • トラブルシューティング ガイド: トラブルシューティング ガイドの [高い一時ファイル数] タブを使用して、問題のあるクエリを特定します。
詳細な調整

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. この方法を使用して値を決定した後、操作のニーズに合わせて、(前述のように) グローバルに、またはより詳細なレベルで適用できます。