Azure Database for PostgreSQL フレキシブルサーバーにおける適応型自動バキューム

この記事では、Azure Database for PostgreSQL フレキシブルサーバーでサポートされる adaptive_autovacuum パラメーターについて記載しています。

adaptive_autovacuum.optimize_configurations: 一連の自動バキューム設定の自動チューニングを有効にします。
adaptive_autovacuum.open_transaction_threshold: 年齢のしきい値を秒単位で設定して、古いプリペアードトランザクションを検出して緩和します。

各パラメーターのしくみ

adaptive_autovacuum.optimize_configurations

このパラメーターを on に設定すると、チューニングサービスは定期的に次の操作を行います。

ワークロードとテーブル統計のシグナルを収集して集計します。
ルールワークフローを評価します。
候補の自動バキュームパラメーターの更新を計算します。
更新プログラムを適用し、エンジンの構成を再読み込みします。
監査エントリを書き込みます。

ルール条件が満たされていない場合、実行は変更なしで完了できます。

現在の調整可能なパラメーター:

autovacuum_vacuum_cost_limit
autovacuum_vacuum_threshold
autovacuum_vacuum_scale_factor
autovacuum_vacuum_cost_delay
autovacuum_analyze_scale_factor

Note

autovacuum_vacuum_cost_limitを -1 に設定すると、ロジックはvacuum_cost_limitから派生します。
チューニングサービスは autovacuum_freeze_max_age を入力信号として使用しますが、直接チューニングすることはありません。

調整済みパラメーターの可視性と上書き動作

この機能が 5 つのターゲットパラメーター (autovacuum_vacuum_cost_limit、 autovacuum_vacuum_threshold、 autovacuum_vacuum_scale_factor、 autovacuum_vacuum_cost_delay、 autovacuum_analyze_scale_factor) のいずれかを変更する場合:

コントロールプレーン構成エンドポイント (GET Configurations API や CLI コマンドグループ az postgres flexible-server parameter など) には、これらの有効なランタイム変更は表示されません。
有効な値を確認するには、PostgreSQL エンドポイントに対してデータプレーンクエリを使用します (たとえば、 SHOW <guc_name> や SELECT name, setting FROM pg_settings WHERE name IN (...))。

ユーザーオーバーライドセマンティクス:

ポータル、REST API、CLI、またはサポートされている SDK のいずれかを使用して、これら 5 つのパラメーターのいずれかを直接設定できます。
コントロールプレーン構成エンドポイントが現在返すのと同じ値にパラメーターを設定した場合、操作は no-op として扱われ、新しい有効な変更は適用されません。
ユーザー設定の値は、適用時に機能が適用された値をオーバーライドします。
adaptive_autovacuum.optimize_configurationsが有効なままの場合、後のチューニングイテレーションでは、ルールの評価に基づいて新しい値を再度適用できます。

adaptive_autovacuum.open_transaction_threshold

このパラメーターは、孤立した準備済みトランザクションの緩和を制御します:

0 は無効を意味します。
0 より大きい値は、しきい値 (秒単位) で有効になっていることを意味します。

有効にすると、最も古い準備済みトランザクションがしきい値を超えた場合、孤立トランザクションハンドラーは適格性を評価し、古い準備済みトランザクションをロールバックできます。ハンドラーは、パラメーターの変更に関するメモリ内しきい値を更新するため、動作は最新の値に従います。

重要なタイミングの詳細:

この機能は、最初に、準備された最も古いトランザクションタイムスタンプを決定します。
その検出はポーリング方式であり、継続的ではありません。
ポーリングは 1,800 秒ごと（つまり 30 分ごと）に実行されるため、緩和措置は、十分に古い準備済みトランザクションがポーリングで検出されて初めて開始できます。

ランタイムとスケジューリングの動作

optimize_configurationsチューニングの周期は 30 分ごとに行われます。
optimize_configurationsを有効にすると、即時チューニング実行がトリガーされ、スケジュールされた実行が続行されます。
open_transaction_thresholdの処理は、準備済みトランザクションの観測結果に基づくイベント駆動です。軽減策は、年齢チェックがしきい値を超えた場合にのみ実行されます。
open_transaction_threshold の準備済みトランザクションの監視情報は 300 秒ごとに更新されます。

有効にした後、 `intelligentperformance` スキーマはいつ作成されますか?

intelligentperformance スキーマは、azure_sys データベースの下に作成されます。これはすぐには作成されません。初回のチューニング実行自体で作成されるのではなく、適応型 autovacuum で使用する統計情報を永続化する機能によって作成されます。通常、スキーマは機能を有効にしてから 0 ~ 30 分以内に作成されます。

アダプティブ自動バキュームを有効にするには、 adaptive_autovacuum.optimize_configurations を on に設定するか、 adaptive_autovacuum.open_transaction_threshold を 0 以外の値 ( > 0) に構成します。スキーマは、機能がアクティブになり、必要な統計の収集を開始すると作成されます。

特定の前提条件が満たされていない場合、作成が遅れたり、スキップされたりする可能性があります。

制限事項と前提条件

どちらのコントロールも、次の要件に従います。

インスタンスはプライマリである必要があります。
PostgreSQL は復旧モードではありません。
サーバーのコンピューティングには、少なくとも 4 つの仮想コアがあります。
サーバーは、エラスティッククラスターではなく、通常のフレキシブルサーバーです。この機能は、エラスティッククラスターではサポートされていません。
adaptive_autovacuum.optimize_configurations は、14 以上のメジャーバージョンでサポートされています。
adaptive_autovacuum.open_transaction_threshold は、13 以上のメジャーバージョンでサポートされています。

監査と可観測性

システムは、両方のコントロールのアクションを intelligentperformance.adaptive_tuning_events という名前の監査ビューに記録します。

ビューのスキーマ

想定される論理図形:

インテリジェントパフォーマンス.適応チューニングイベント
- イベントの詳細
- optimizer_type
- applied_at

最近のアクティビティのクエリ

最近のアクティビティに対してクエリを実行するには、次のクエリを使用します。

SELECT
    applied_at,
    optimizer_type,
    event_details
FROM intelligentperformance.adaptive_tuning_events
ORDER BY applied_at DESC
LIMIT 100;

SELECT
    optimizer_type,
    COUNT(*) AS events
FROM intelligentperformance.adaptive_tuning_events
WHERE applied_at >= now() - interval '7 days'
GROUP BY optimizer_type
ORDER BY events DESC;

イベントの種類と解釈

optimizer_type列はアクションソースを示します。

適応型自動バキューム設定が変更されました

ソース:

optimize_configurations チューニングパス。

ペイロードの形状:

パラメーター変更レコードの JSON 配列(通常は次を含む):
- server_parameter_name
- 前の値
- 更新済みの調整値

"解釈:

自動バキュームのチューニングによってサーバー設定が変更されたことを示します。
その後のワークロード指標が改善した場合は良好（デッドタプル負荷、VACUUM の実行頻度、レイテンシ、CPU/IO）。
変化が頻繁でオシレーターであり、その後に回帰が続く場合、負の可能性があります。

SELECT
    applied_at,
    elem->>'server_parameter_name' AS parameter_name,
    elem->>'previous_value' AS previous_value,
    elem->>'updated_tuned_value' AS updated_value
FROM intelligentperformance.adaptive_tuning_events e
CROSS JOIN LATERAL jsonb_array_elements(e.event_details) AS elem
WHERE e.optimizer_type = 'adaptive_autovacuum_configuration_changed'
ORDER BY applied_at DESC;

orphan_transaction_rollback

ソース:

open_transaction_threshold 軽減パス。

ペイロードの形状:

ロールバック結果の詳細 (たとえば、GID ロールバック情報の試行と成功) を含む、データベースによってキー付けされた JSON オブジェクト。

{
    "<example-database-name>": {
        "Timestamp": "2026-03-22T18:20:22.0000000Z", 
        "RollbackGids": ["<example-global-identifier-one>", "<example-global-identifier-two>"], 
        "OperationSuccessful": true
    }
}

"解釈:

準備済みトランザクションがしきい値を超過したため、強制的にロールバックされたことを示します。
不定期のイベントは、正常な保護動作になる可能性があります。
通常、頻繁なイベントは、調査する必要があるアプリケーショントランザクションライフサイクルの問題を示します。

SELECT
    applied_at,
    jsonb_pretty(event_details) AS rollback_details
FROM intelligentperformance.adaptive_tuning_events
WHERE optimizer_type = 'orphan_transaction_rollback'
ORDER BY applied_at DESC
LIMIT 50;

影響が肯定的か否定的かを判断する

optimize_configurationsの場合:

adaptive_autovacuum_configuration_changedから変更タイムスタンプを識別します。
変更後30～120分の観測期間について、デッドタプル数、VACUUM/ANALYZE の実行頻度、レイテンシ、CPU/IO を比較する。

open_transaction_thresholdの場合:

orphan_transaction_rollbackイベントを識別します。
ロールバックの頻度が低く、安定しているかどうかを検証します。
ロールバックイベントが永続的な場合は、アプリケーションの動作を調査します。

SELECT
    applied_at,
    optimizer_type,
    event_details
FROM intelligentperformance.adaptive_tuning_events
WHERE applied_at >= now() - interval '7 days'
ORDER BY applied_at DESC;

保持とハウスキープ処理

ハウスキーピングは、90 日間の固定および構成不可能な保持期間を使用して、監査ストレージから古いレコードを削除します。

長期的なトレンド分析を行うには、監査ログを独自のオブザーバビリティストアにエクスポートしてください。

インテリジェントなチューニング。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-08-14