AnalyticDB:パフォーマンスパラメータの最適化

パラメータレベル

AnalyticDB for PostgreSQLには4つのパラメーターレベルがあります。 特定のパラメータは、特定のレベルでのみ設定できます。

ALTER DATABASE name SET parameter { TO | = } { value | DEFAULT };

ALTER ROLE name SET parameter  { TO | = } { value | DEFAULT };

SET parameter  { TO | = } { value | DEFAULT };

次の表に、チケットを送信して変更できるシステムレベルのパラメーターを示します。

上記のパラメーターの詳細については、「設定パラメーター」をご参照ください。

パラメータ説明

次の表に、AnalyticDB for PostgreSQLのパフォーマンス関連パラメーターを示します。

• 接続関連のパラメータ

  パラメーター	条件を有効にする	依存関係	説明
  max_connections	インスタンスの再起動	計算ノードのこのパラメーターの値は、コーディネーターノードのこのパラメーターの値の3〜5倍である必要があります。	ノードとデータベースサーバー間の同時接続の最大数。 このパラメーターは、コーディネーターと計算ノードごとに個別に設定する必要があります。 max_connections値の代わりにrds_max_non_super_conns値を調整することを推奨します。 短期間の接続が非常に同時並行であるシナリオでは、rds_max_non_super_connsパラメーターを、500とmax_connectionsの間の値に変更できます。 rds_max_super_connsパラメーターはスーパーユーザーに関連しており、ほとんどの場合調整する必要はありません。
  max_prepared_トランザクション	インスタンスの再起動	このパラメーターは、max_connectionsの値と同じ値に設定することを推奨します。 max_prepared_transactionsの値の2倍は、rds_max_non_super_conns値にrds_max_super_conns値を加えた値より大きくなければなりません。	2フェーズコミット (2PC) 状態のトランザクション数。 このパラメーターは、max_connectionsの値と同じ値に設定することを推奨します。 同時実行性の高いシナリオでエラーが発生した場合は、この値を増やす必要があります。
  rds_max_non_super_conns	設定のリロード	この値は、max_connections値未満である必要があります。 rds_max_non_super_conns値とrds_max_super_conns値は、max_connections値以下である必要があります。 計算ノードのこのパラメーターの値は、コーディネーターノードのこのパラメーターの値の3〜5倍である必要があります。	非スーパーユーザーが使用できる接続の最大数。
  rds_max_super_conns	設定のリロード	この値は、max_connections値未満である必要があります。 rds_max_non_super_conns値とrds_max_super_conns値は、max_connections値以下である必要があります。 計算ノードのこのパラメーターの値は、コーディネーターノードのこのパラメーターの値の3〜5倍である必要があります。	スーパーユーザーが使用できる接続の最大数。

• メモリ制御パラメータ

  パラメーター	有効値 /単位	条件を有効にする	依存関係	説明
  shared_buffers	KB	インスタンスの再起動	ほとんどのデータが行指向のテーブルに格納されている場合は、この値をインスタンスのメモリサイズの25% か、計算ノードの場合は少し大きく設定することを推奨します。	共有バッファーのサイズ。 このパラメーターは、コーディネーターと計算ノードごとに個別に設定する必要があります。 コーディネーターノードのキャッシュページにはデータ辞書テーブルが含まれ、コンピュートノードのキャッシュページには行指向テーブルが含まれます。 追加最適化列指向 (AOCO) テーブルは、共有バッファのサイズの影響を受けません。 ほとんどの場合、このパラメーターを変更する必要はありません。 100,000を超えるテーブルが作成されている場合は、コーディネーターノードと計算ノードに対してこの値を増やすことを推奨します。 ほとんどのデータが行指向のテーブルに格納されている場合は、計算ノードでこの値を増やすことをお勧めします。
  temp_buffers	KB	設定のリロード	なし	一時バッファーのサイズ。 一時バッファは、データベースセッションが一時テーブルにアクセスするために使用されます。 このパラメーターのデフォルト値は8 MBです。 大きな一時テーブルへのアクセスのパフォーマンスを向上させるために、特定のセッションに対してこのパラメーターを変更できます。
  gp_vmem_protect_limit	KB	インスタンスの再起動	gp_vmem_protect_limit = gp_vmem/acting_primary_segments	計算ノード上のすべてのpostgresプロセスで使用できるメモリの最大量。 単位：MB。 この値を超えるメモリサイズが必要な場合、クエリは失敗します。 このパラメーターは、プライマリおよびセカンダリ計算ノードごとに個別に設定する必要があります。 次の式に基づいて、このパラメーターの適切な値を推定できます。 gp_vmem = ((SWAP + RAM) - (7.5 GB + 0.05 × RAM))/1.7 gp_vmem_protect_limit = gp_vmem/acting_primary_segments acting_primary_segment値は、プライマリ計算ノードの数、またはプライマリとセカンダリの計算ノードを組み合わせた数です。 クエリが失敗した場合は、この値を増やす必要があります。 説明 リソースキューのメモリ制限を設定する場合は、リソースキューのパラメーターを変更することを推奨します。 詳細については、「リソースキューを使用したワークロード管理」をご参照ください。
  gp_vmem_protect_segworker_cache_limit	KB	インスタンスの再起動	なし	クエリ実行プロセスの最大キャッシュ。 多数の接続またはアイドルプロセスがある場合、計算ノードからより多くのメモリを解放するために、この値を減らす必要がある場合があります。 このパラメーターは、計算ノードごとに個別に設定する必要があります。
  gp_resqueue_memory_ポリシー	none、auto、eager_free	設定のリロード	なし	AnalyticDB for PostgreSQLで使用されるメモリ管理ポリシー。 クエリプランにはいくつかのステージがあります。 このパラメーターがeager_freeに設定されている場合、AnalyticDB for PostgreSQLは、このステージの最後のステージに割り当てられたメモリを解放し、次のステージにメモリを割り当てます。 eager_free値はメモリ不足の可能性を減らしますが、パフォーマンスのオーバーヘッドが増えます。 このパラメーターがautoに設定されている場合、クエリのメモリ使用量はstatement_memとリソースキューのメモリ制限に基づいて制御されます。
  ステートメント_mem	KB	設定のリロード	このパラメーターは、gp_resqueue_memory_policyがautoに設定されている場合に有効です。 この値は、max_statement_mem値より大きくすることはできません。	各クエリに割り当てられたホストメモリ。 このパラメーターに基づいて割り当てられるメモリの量は、max_statement_memまたはクエリの送信に使用されるリソースキューのメモリ制限を超えることはできません。 gp_resqueue_memory_policyがautoに設定されている場合、クエリのメモリ使用量はstatement_memとリソースキューのメモリ制限に基づいて制御されます。 クエリにさらにメモリが必要な場合は、ディスク上の一時的なスピルファイルが使用されます。 次の式に基づいて、このパラメーターの適切な値を推定できます。 (gp_vmem_protect_limit GB × 0.9)/max_expected_concurrent_queries gp_vmem_protect_limitが8192 MB (8 GB) に設定されており、10% バッファを使用して最大40の同時クエリが想定されている場合、次の値を計算できます。 (8GB × 0.9)/40 = 184 MB
  max_statement_mem	KB	設定のリロード	(seghost_physical_memory)/(average_number_concurrent_queries)	クエリに割り当てることができるメモリの最大量。 このパラメーターは、statement_memが高い値に設定されている場合、クエリ処理中に計算ノードでメモリ不足エラーを回避するのに役立ちます。 gp_resqueue_memory_policyがautoに設定されている場合、クエリのメモリ使用量はstatement_memとリソースキューのメモリ制限に基づいて制御されます。 この値は, 単一の計算ノードホストの構成を考慮して, 次の計算式で計算できます。 (seghost_physical_memory)/(average_number_concurrent_queries)

• ワークロード関連のパラメーター

  パラメーター	有効値 /データ型	条件を有効にする	依存関係	説明
  gp_resqueue_priority	BOOLEAN	インスタンスの再起動	なし	クエリの優先順位付けを有効にするか無効にするかを指定します。 クエリの優先順位が無効になっている場合、既存の優先順位設定はクエリ実行時に評価されません。 高いクエリパフォーマンスが必要なシナリオでは、優先度キューを無効にすることを推奨します。
  gp_resqueue_priority_cpucores_per_セグメント	512.0に0.1	インスタンスの再起動	なし	インスタンスの作成時に指定される、インスタンスの各計算ノードに割り当てられたCPUコアの数。 このパラメーターが不適切に設定されていると、CPUが十分に使用されず、クエリの優先順位が正しく機能しない可能性があります。
  gp_resqueue_priority_sweeper_interval	500 ms ~ 15000 ms	インスタンスの再起動	gp_resqueue_priority	すべてのステートメントでCPU使用率が再計算される間隔。 ステートメントが実行されているとき、そのCPUシェアは優先度とgp_resqueue_priority_cpucores_per_segmentに基づいて計算されます。 間隔が小さく、計算の頻度が高いほど、優先順位の設定によって達成される結果が良くなり、オーバーヘッドが大きくなります。