Azure Database for PostgreSQL - フレキシブル サーバーのサーバー パラメーター

  • [アーティクル]

適用対象: Azure Database for PostgreSQL - フレキシブル サーバー

Azure Database for PostgreSQL には、各サーバーの構成可能なパラメーターのサブセットが用意されています。 Postgres パラメーターの詳細については、 PostgreSQL のドキュメントを参照してください。

パラメーターの種類

Azure Database for PostgreSQL - フレキシブル サーバーは、各パラメータに対して最適な既定の設定で事前構成されています。 パラメータは、次の種類のいずれかに分類されます。

  • 静的: これらのパラメーターでは、変更を実装するためにサーバーの再起動が必要です。
  • 動的: これらのパラメーターは、サーバー インスタンスを再起動しなくても変更できます。 ただし、変更は、変更後に確立された新しい接続にのみ適用されます。
  • 読み取り専用: これらのパラメーターは、サービスの信頼性、セキュリティ、またはその他の運用面を維持する上で重要な役割を果たしているため、ユーザーが構成できません。

パラメーターの種類を確認するには、Azure portal に移動し、[サーバー パラメーター] ペインを開きます。 簡単に識別できるように、パラメーターはタブにグループ化されています。

クラスターのカスタマイズ

さまざまなメソッドとレベルを使用して、特定のニーズに応じてパラメータをカスタマイズできます。

グローバル レベル

インスタンスまたはサーバー レベルで設定をグローバルに変更するには、Azure portal の [サーバー パラメーター] ペインに移動します。 Azure CLI、REST API、Azure Resource Manager テンプレート、パートナー ツールなど、他の利用可能なツールを使用することもできます。

Note

Azure Database for PostgreSQL はマネージド データベース サービスであるため、ユーザーは、postgresql.conf などの構成ファイルを表示または変更するためにホストやオペレーティング システムにアクセスできません。 ファイルの内容は、パラメーターに加えた変更に基づいて自動的に更新されます。

Azure portal の [サーバー パラメーター] のペインのスクリーンショット。

詳細なレベル

より詳細なレベルでパラメーターを調整できます。 これらの調整はグローバルに設定された値をオーバーライドできます。 そのスコープと期間は、行われるレベルによって異なります。

  • データベース レベル: データベース固有の構成に ALTER DATABASE コマンドを使用します。

  • ロールまたはユーザー レベル: ユーザー中心の設定には、ALTER USER コマンドを使用します。

  • 関数、プロシージャ レベル: 関数またはプロシージャを定義するときに、関数の呼び出し時に設定される構成パラメーターを指定または変更できます。

  • テーブル レベル: たとえば、このレベルで自動バキュームに関連するパラメータを変更できます。

  • セッション レベル: 個々のデータベース セッションの期間中、特定のパラメータを調整できます。 PostgreSQL では、次の SQL コマンドを使用してこの調整を促進します。

    • SET コマンドを使用して、セッション固有の調整を行います。 これらの変更は、現在のセッション中に既定の設定として機能します。 これらの変更にアクセスするには、特定の SET 特権が必要な場合があり、前述の変更可能および読み取り専用のパラメーターに関する制限は適用されません。 対応する SQL 関数は set_config(setting_name, new_value, is_local) です。
    • SHOW コマンドを使用して、既存のパラメーター設定を調べます。 同等の SQL 関数は current_setting(setting_name text) です。

重要なパラメーター

以下のセクションでは、いくつかのパラメーターについて説明します。

shared_buffers

属性 Value
規定値 合計 RAM の 25%
許可されている値 合計 RAM の 10 から 75%
Type Static
Level グローバル
Azure 固有の注 shared_buffers 設定は、階層で仮想コアが増えると、(ほぼ) 線形的にスケーリングされます。

説明

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

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

huge_pages

属性 Value
規定値 TRY
許可されている値 TRY、ON、OFF
Type Static
Level グローバル
Azure 固有の注 4 つ以上の仮想コアを持つサーバーの場合、基になるオペレーティング システムから大型のページが自動的に割り当てられます。 この機能は、仮想コア数が 4 未満のサーバーでは使用できません。 shared_buffers への変更など、共有メモリ設定が変更されると、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 で維持します。

work_mem

属性 Value
規定値 4MB
許可されている値 4MB-2GB
Type 動的
Level グローバルで詳細

説明

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

maintenance_work_mem

属性 Value
規定値 サーバー メモリに依存します
許可されている値 1MB-2GB
Type 動的
Level グローバルで詳細

説明

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 のサブセットとして機能します。 他のメンテナンス タスクやデータ定義操作へのメモリ割り当てに影響を与えることなく、自動バキュームが使うメモリ量を決定できます。

次のステップ

サポートされている PostgreSQL 拡張機能の詳細については、「Azure Database for PostgreSQL - フレキシブル サーバーの PostgreSQL 拡張機能」をご覧ください。