リソース使用量/メモリ
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 の構成パラメーターです。 VACUUM、CREATE INDEX、ALTER 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 の一時ファイルが生成されている場合:
- psql または任意の PostgreSQL クライアントを使用してデータベースに接続します。
- メモリ内での処理時に追加のヘッダーを考慮するように、初期の
work_mem値を 20 MB より少し高く設定します。SET work_mem TO '25MB'などのコマンドを使用します。 - 同じセッションで問題のあるクエリに対して
EXPLAIN ANALYZEを実行します。 "Sort Method: quicksort Memory: xkB"の出力を確認します。"external merge Disk: xkB"を示す場合は、work_mem値を段階的に上げ、"quicksort Memory"が表示されるまで再テストします。"quicksort Memory"が表示されると、クエリがメモリ内で動作していることを示します。- この方法を使用して値を決定した後、操作のニーズに合わせて、(前述のように) グローバルに、またはより詳細なレベルで適用できます。
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 の構成パラメーターです。 VACUUM、CREATE INDEX、ALTER 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 の一時ファイルが生成されている場合:
- psql または任意の PostgreSQL クライアントを使用してデータベースに接続します。
- メモリ内での処理時に追加のヘッダーを考慮するように、初期の
work_mem値を 20 MB より少し高く設定します。SET work_mem TO '25MB'などのコマンドを使用します。 - 同じセッションで問題のあるクエリに対して
EXPLAIN ANALYZEを実行します。 "Sort Method: quicksort Memory: xkB"の出力を確認します。"external merge Disk: xkB"を示す場合は、work_mem値を段階的に上げ、"quicksort Memory"が表示されるまで再テストします。"quicksort Memory"が表示されると、クエリがメモリ内で動作していることを示します。- この方法を使用して値を決定した後、操作のニーズに合わせて、(前述のように) グローバルに、またはより詳細なレベルで適用できます。
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 の構成パラメーターです。 VACUUM、CREATE INDEX、ALTER 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 の一時ファイルが生成されている場合:
- psql または任意の PostgreSQL クライアントを使用してデータベースに接続します。
- メモリ内での処理時に追加のヘッダーを考慮するように、初期の
work_mem値を 20 MB より少し高く設定します。SET work_mem TO '25MB'などのコマンドを使用します。 - 同じセッションで問題のあるクエリに対して
EXPLAIN ANALYZEを実行します。 "Sort Method: quicksort Memory: xkB"の出力を確認します。"external merge Disk: xkB"を示す場合は、work_mem値を段階的に上げ、"quicksort Memory"が表示されるまで再テストします。"quicksort Memory"が表示されると、クエリがメモリ内で動作していることを示します。- この方法を使用して値を決定した後、操作のニーズに合わせて、(前述のように) グローバルに、またはより詳細なレベルで適用できます。
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 の構成パラメーターです。 VACUUM、CREATE INDEX、ALTER 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 の一時ファイルが生成されている場合:
- psql または任意の PostgreSQL クライアントを使用してデータベースに接続します。
- メモリ内での処理時に追加のヘッダーを考慮するように、初期の
work_mem値を 20 MB より少し高く設定します。SET work_mem TO '25MB'などのコマンドを使用します。 - 同じセッションで問題のあるクエリに対して
EXPLAIN ANALYZEを実行します。 "Sort Method: quicksort Memory: xkB"の出力を確認します。"external merge Disk: xkB"を示す場合は、work_mem値を段階的に上げ、"quicksort Memory"が表示されるまで再テストします。"quicksort Memory"が表示されると、クエリがメモリ内で動作していることを示します。- この方法を使用して値を決定した後、操作のニーズに合わせて、(前述のように) グローバルに、またはより詳細なレベルで適用できます。
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 の構成パラメーターです。 VACUUM、CREATE INDEX、ALTER 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 の一時ファイルが生成されている場合:
- psql または任意の PostgreSQL クライアントを使用してデータベースに接続します。
- メモリ内での処理時に追加のヘッダーを考慮するように、初期の
work_mem値を 20 MB より少し高く設定します。SET work_mem TO '25MB'などのコマンドを使用します。 - 同じセッションで問題のあるクエリに対して
EXPLAIN ANALYZEを実行します。 "Sort Method: quicksort Memory: xkB"の出力を確認します。"external merge Disk: xkB"を示す場合は、work_mem値を段階的に上げ、"quicksort Memory"が表示されるまで再テストします。"quicksort Memory"が表示されると、クエリがメモリ内で動作していることを示します。- この方法を使用して値を決定した後、操作のニーズに合わせて、(前述のように) グローバルに、またはより詳細なレベルで適用できます。
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 の構成パラメーターです。 VACUUM、CREATE INDEX、ALTER 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 の一時ファイルが生成されている場合:
- psql または任意の PostgreSQL クライアントを使用してデータベースに接続します。
- メモリ内での処理時に追加のヘッダーを考慮するように、初期の
work_mem値を 20 MB より少し高く設定します。SET work_mem TO '25MB'などのコマンドを使用します。 - 同じセッションで問題のあるクエリに対して
EXPLAIN ANALYZEを実行します。 "Sort Method: quicksort Memory: xkB"の出力を確認します。"external merge Disk: xkB"を示す場合は、work_mem値を段階的に上げ、"quicksort Memory"が表示されるまで再テストします。"quicksort Memory"が表示されると、クエリがメモリ内で動作していることを示します。- この方法を使用して値を決定した後、操作のニーズに合わせて、(前述のように) グローバルに、またはより詳細なレベルで適用できます。
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 の構成パラメーターです。 VACUUM、CREATE INDEX、ALTER 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 の一時ファイルが生成されている場合:
- psql または任意の PostgreSQL クライアントを使用してデータベースに接続します。
- メモリ内での処理時に追加のヘッダーを考慮するように、初期の
work_mem値を 20 MB より少し高く設定します。SET work_mem TO '25MB'などのコマンドを使用します。 - 同じセッションで問題のあるクエリに対して
EXPLAIN ANALYZEを実行します。 "Sort Method: quicksort Memory: xkB"の出力を確認します。"external merge Disk: xkB"を示す場合は、work_mem値を段階的に上げ、"quicksort Memory"が表示されるまで再テストします。"quicksort Memory"が表示されると、クエリがメモリ内で動作していることを示します。- この方法を使用して値を決定した後、操作のニーズに合わせて、(前述のように) グローバルに、またはより詳細なレベルで適用できます。