AnalyticDB for PostgreSQL は、ほとんどのユースケースですぐに使用できます。しかし、高い接続同時実行性、メモリ集約型のクエリ、または優先度が混在するワークロードなど、特定のパフォーマンス要件があるシナリオでは、データベースパラメーターをチューニングすることで、スループットとリソース使用率を大幅に向上させることができます。
パラメーターレベル
パラメーターは 4 つのレベルで適用されます。下位レベルで設定されたパラメーターは、そのスコープにおいて上位レベルの同じパラメーターをオーバーライドします。
| レベル | スコープ | 設定方法 |
|---|---|---|
| システム | インスタンス内のすべてのデータベースにわたるすべてのユーザー | 運用保守 (O&M) 担当者にチケットを起票 |
| データベース | 指定されたデータベース内のすべてのセッション | ALTER DATABASE name SET parameter { TO | = } { value | DEFAULT }; |
| ロール | 指定されたユーザーのすべてのセッション | ALTER ROLE name SET parameter { TO | = } { value | DEFAULT }; |
| セッション | 現在のセッションのみ | SET parameter { TO | = } { value | DEFAULT }; |
セッションレベルのチューニングから始めてください。変更が他のユーザーやワークロードに影響を与えないことを確認した後にのみ、上位レベルのパラメーターを変更してください。
パラメーターの現在値の確認
パラメーターを変更する前に、その現在値を確認します。
-- 現在のセッションで特定のパラメーターを確認
SHOW statement_mem;
-- 現在のデータベースのすべてのパラメーターを確認
SELECT name, setting, unit, context FROM pg_settings WHERE name = 'statement_mem';システムレベルのパラメーター
以下のパラメーターを変更するには、チケットの起票が必要です。詳細については、Greenplum 構成パラメーターリファレンスをご参照ください。
| パラメーター | デフォルト値 | タイプ/単位 | 有効な値 |
|---|---|---|---|
gp_autostats_mode | ON_NO_STATS | STRING | NONE, ON_CHANGE, ON_NO_STATS |
gp_autostats_mode_in_functions | NONE | STRING | NONE, ON_CHANGE, ON_NO_STATS |
gp_max_slices | 50 | INT | 0–1000 |
log_rotation_size | 102400 | KB | 0–4194304 |
master.rds_enable_vmem_protect | on | STRING | on, off |
master.rds_max_non_super_conns | 500 | INT | 10–1000 |
max_stack_depth | 2048 | KB | 100–2048000 |
max_statement_mem | 2048000 | KB | 32768–2147483647 |
optimizer | on | STRING | on, off |
random_page_cost | 4 | DOUBLE | 0–1000 |
rds.rds_enable_aliyun_oss_endpoint | on | STRING | on, off |
rds.rds_enable_oss_endpoint_whitelist_check | on | STRING | on, off |
rds_max_super_conns | 50 | INT | 10–100 |
segment.rds_enable_vmem_proctect | off | STRING | on, off |
segment.rds_max_non_super_conns | 1000 | INT | 10–3000 |
statement_mem | 2047000 | KB | 50–2147483647 |
statement_timeout | 10800000 | INT | 0–2147483647 |
接続パラメーター
これらのパラメーターは、インスタンスが受け入れる同時接続数を制御します。設定を誤ると、高い同時実行性のシナリオで接続エラーが発生する可能性があります。
| パラメーター | 有効になるタイミング | 依存関係 | 説明 |
|---|---|---|---|
max_connections | インスタンスの再起動 | コンピュートノードの値は、コーディネーターノードの値の 3～5 倍である必要があります | ノードあたりの最大同時接続数です。max_connections を直接増やすのではなく、代わりに rds_max_non_super_conns を調整してください。このパラメーターは再起動なしで有効になります。同時実行性が高い短時間接続の場合は、rds_max_non_super_conns を 500 から max_connections の値の間の値に設定します。 |
max_prepared_transactions | インスタンスの再起動 | max_connections と同じ値に設定します。2 × max_prepared_transactions は rds_max_non_super_conns + rds_max_super_conns を超える必要があります。 | 2フェーズコミット (2PC) 状態のトランザクションの最大数です。高い同時実行性のもとでエラーが発生した場合は、この値を増やしてください。 |
rds_max_non_super_conns | 設定のリロード | max_connections より小さい値にする必要があります。rds_max_non_super_conns + rds_max_super_conns は max_connections を超えてはなりません。コンピュートノードの値は、コーディネーターノードの値の 3～5 倍である必要があります。 | スーパーユーザー以外の最大接続数です。接続制限を管理するには、このパラメーターを調整することが推奨されます。 |
rds_max_super_conns | 設定のリロード | rds_max_non_super_conns と同じ制約です。 | スーパーユーザーの最大接続数です。ほとんどの場合、調整は不要です。 |
接続制限に達した場合： rds_max_non_super_conns を引き上げます (再読み込みで即座に反映されます)。上限がすでに max_connections になっている場合は、まず max_connections を引き上げてから (再起動が必要です)、rds_max_non_super_conns を引き上げます。
メモリパラメーター
これらのパラメーターは、クエリにメモリを割り当て、セッション間で共有する方法を制御します。メモリ不足 (OOM) エラーでクエリが失敗する場合や、メモリが十分に活用されていない場合に、これらのパラメーターをチューニングします。
| パラメーター | 単位 | 有効になるタイミング | 依存関係 | 説明 |
|---|---|---|---|---|
shared_buffers | KB | インスタンスの再起動 | 行指向テーブルのワークロードの場合、コンピュートノードでインスタンスメモリの 25% 以上に設定します。 | 共有バッファプールのサイズ。コーディネーターノードとコンピュートノードで個別に設定します。コーディネーターノードのキャッシュにはデータディクショナリテーブルが保持され、コンピュートノードは行指向テーブルをキャッシュします。Append-optimized column-oriented (AOCO) テーブルはこの設定の影響を受けません。インスタンスに 100,000 を超えるテーブルがある場合は、コーディネーターノードとコンピュートノードの両方でこの値を増やしてください。 |
temp_buffers | KB | 構成の再読み込み | — | セッションレベルで一時テーブルにアクセスするために使用される一時バッファのサイズ。デフォルト：8 MB。大規模な一時テーブルのパフォーマンスを向上させるには、セッションレベルでこの値を増やします。 |
gp_vmem_protect_limit | MB | インスタンスの再起動 | gp_vmem_protect_limit = gp_vmem / acting_primary_segments | gp_vmem = ((SWAP + RAM) - (7.5 GB + 0.05 × RAM)) / 1.7gp_vmem_protect_limit = gp_vmem / acting_primary_segmentsコンピュートノード上のすべての postgres プロセスが使用できる最大メモリ。クエリがこの制限を超えるメモリを必要とする場合、クエリは失敗します。プライマリおよびセカンダリのコンピュートノードで個別に設定します。適切な値を計算します：`gp_vmem = ((SWAP + RAM) - (7.5 GB + 0.05 × RAM)) / 1.7`、次に `gp_vmem_protect_limit = gp_vmem / acting_primary_segments`。メモリ不足エラーでクエリが失敗する場合は、この値を増やしてください。クエリごとのメモリ制限を設定するには、代わりにリソースキューパラメーターを使用します。詳細については、「ワークロード管理のためのリソースキューの使用」をご参照ください。 |
gp_vmem_protect_segworker_cache_limit | KB | インスタンスの再起動 | — | コンピュートノード上のクエリエグゼキュータプロセスごとにキャッシュされる最大メモリ。インスタンスに多数の接続またはアイドルプロセスがある場合は、この値を減らしてアクティブなクエリのためにメモリを解放します。各コンピュートノードで個別に設定します。 |
gp_resqueue_memory_policy | — | 構成の再読み込み | — | メモリ管理ポリシー。eager_free は、各クエリプランステージの終了時にメモリを解放し、次のステージで利用可能にします — OOM のリスクを低減しますが、オーバーヘッドが発生します。auto は、statement_mem およびリソースキューのメモリ制限に基づいてメモリを割り当てます。 |
statement_mem | KB | 構成の再読み込み | gp_resqueue_memory_policy が auto に設定されている場合に有効になります。max_statement_mem を超えてはなりません。 | ホスト上のクエリごとに割り当てられるメモリ。クエリがこの制限を超えるメモリを必要とする場合、一時ディスクファイルにスピルされます。適切な値は、次の式で計算します: statement_mem = (gp_vmem_protect_limit GB × 0.9) / max_expected_concurrent_queries。 例えば、gp_vmem_protect_limit = 8 GB で、想定される同時クエリ数が 40 の場合、(8 GB × 0.9) / 40 = 184 MB となります。 |
max_statement_mem | KB | 構成の再読み込み | (seghost_physical_memory) / (average_number_concurrent_queries) | クエリごとのメモリ割り当ての上限値。コンピュートノードで statement_mem の値が高すぎた場合に OOM エラーを防止します。適切な値を計算します：max_statement_mem = seghost_physical_memory / average_number_concurrent_queries。 |
ワークロードパラメーター
これらのパラメーターは、同時実行ワークロード間での CPU 割り当てとクエリの優先度付けを制御します。
| パラメーター | 有効な値 | 有効になるタイミング | 依存関係 | 説明 |
|---|---|---|---|---|
gp_resqueue_priority | BOOLEAN | インスタンスの再起動 | — | クエリの優先度付けを有効または無効にします。無効にすると、リソースキューの優先度設定はランタイムに影響を与えません。すべてのクエリが CPU を平等に競合すべき遅延の影響を受けやすいシナリオでは、優先度付けを無効にします。 |
gp_resqueue_priority_cpucores_per_segment | 0.1–512.0 | インスタンスの再起動 | — | 各コンピュートノードに割り当てられる CPU コアの数。インスタンス作成時の実際の CPU 数と一致するように設定します。値が正しくないと、CPU の非効率な利用が発生し、クエリの優先度付けの信頼性が低下します。 |
gp_resqueue_priority_sweeper_interval | 500–15000 ms | インスタンスの再起動 | gp_resqueue_priority が有効である必要があります | アクティブなクエリの CPU 使用率が再計算される間隔。間隔を短くすると、優先度付けの精度が向上しますが、CPU オーバーヘッドが増加します。 |
gp_resqueue_priority のトレードオフ： クエリの優先度付けを無効にすると、スケジューリングのオーバーヘッドが解消され、均一なワークロードのスループットが向上する可能性があります。ワークロードに遅延の影響を受けやすいクエリとバッチクエリが混在している場合は、優先度付けを有効にし、リソースキューを介して優先度を割り当ててください。詳細については、「ワークロード管理のためのリソースキューの使用」をご参照ください。