GreenPlumパラメータ設定の最適化

GreenPlumデータベースのパフォーマンスを最大化するためには、適切なパラメータ設定が不可欠です。本記事では、GreenPlumの主要な設定パラメータをカテゴリ別に解説し、最適化のための具体的な推奨値と設定方法を紹介します。

パラメータの確認と変更コマンド

GreenPlumのパラメータは、gpconfigユーティリティを使用して管理します。

• パラメータの現在値を確認する:

gpconfig --show max_connections

• パラメータの値を変更する:

gpconfig -c <parameter_name> -v <parameter_value>
# 例: gpconfig -c log_statement -v DDL
# 設定を削除する: gpconfig -r <parameter_name>

主要なパラメータと推奨設定

1. メモリ関連パラメータ

これらのパラメータは、データベースのメモリ使用量を制御し、クエリの実行効率に直接影響します。

sort_mem

（グローバル、物理メモリの2%-4%）
各セグメントがソートやハッシュ操作に使用するメモリのサイズです。PostgreSQLが大規模なテーブルをソートする際、このパラメータで指定されたサイズに基づいてデータを分割してソートし、中間結果を一時ファイルに保存します。この値を増やすことで、一時ファイルの数を減らし、ソートのパフォーマンスを向上させることができます。ただし、値を過剰に設定するとスワップが発生する可能性があるため、注意が必要です。

# 現在の設定値を確認
gpconfig -s sort_mem

# 設定を変更
gpconfig -c sort_mem -v 256MB

maintenance_mem

（グローバル）
CREATE INDEXやVACUUMなどのメンテナンス操作に使用されるメモリのサイズです。デフォルトは16MBです。これらの操作は通常、並行実行されることが少ないため、sort_memよりも大きな値を設定しても安全です。大きな値を設定することで、メンテナンス操作の速度を向上させることができます。

# 現在の設定値を確認
gpconfig -s maintenance_mem

# 設定を変更
gpconfig -c maintenance_mem -v 512MB

statement_mem

各クエリがセグメントで使用できるメモリの量を設定します。この値は、max_statement_memで設定された上限を超えることはできません。リソースキューが設定されている場合、そのキューの制限も考慮されます。クエリがこのメモリを超える必要がある場合、データはディスクにスピルされます。

# 現在の設定値を確認
gpconfig -s statement_mem

# 設定を変更
gpconfig -c statement_mem -v 512MB

max_statement_mem

各クエリが使用できるメモリの最大量を制限します。これにより、statement_memの設定ミスによるメモリオーバーフローを防ぎます。

# 現在の設定値を確認
gpconfig -s max_statement_mem

# 設定を変更
gpconfig -c max_statement_mem -v 2048MB

vmem_protect_limit

各セグメントデータベースが、実行中のすべてのクエリに割り当てることのできるメモリの総量を制御します。クエリがこの制限を超えるメモリを要求した場合、クエリは失敗します。この値は、物理RAMまたはスワップ領域の量、および各ホスト上のセグメント数に基づいて計算されます。

# 現在の設定値を確認
gpconfig -s vmem_protect_limit

# 設定を変更
gpconfig -c vmem_protect_limit -v 16384MB
gpstop -u

workfile_limit_files_per_query

SQLクエリが使用できる一時ファイル（スピルファイル）の最大数を制限します。メモリ不足時に、GreenPlumは一時ファイルを作成します。このパラメータは、1つのクエリが作成できる一時ファイルの数を制限します。0は無制限を意味します。この制限を設定することで、問題のあるクエリがシステム全体に影響を与えるのを防ぎます。

# 現在の設定値を確認
gpconfig -s workfile_limit_files_per_query

# 設定を変更
gpconfig -c workfile_limit_files_per_query -v 50000

effective_cache_size

（マスターノード、物理メモリの85%程度）
PostgreSQLのオプティマイザに、データをキャッシュするために使用可能なメモリの量を通知します。この値は、インデックスの使用を決定するのに役立ちます。この値が大きいほど、オプティマイザはインデックスを使用する可能性が高くなります。この値は、shared_buffersと利用可能なOSキャッシュの合計値に設定するのが理想的です。

# 現在の設定値を確認
gpconfig -s effective_cache_size

# 設定を変更
gpconfig -c effective_cache_size -v 32768MB

2. 接続とプロセス管理パラメータ

これらのパラメータは、データベースへの接続数やプロセスのリソース使用を制御します。

max_connections

GreenPlumデータベースシステムへのアクティブな同時セッション数を制限します。これはローカルパラメータであり、マスター、スタンバイマスター、および各セグメントインスタンス（プライマリセグメントとミラーセグメント）のpostgresql.confファイルで設定する必要があります。セグメント上のmax_connectionsの値は、マスター上の値の5〜10倍にする必要があります。

# 現在の設定値を確認
gpconfig -s max_connections

# 設定を変更
gpconfig -c max_connections -v 300 -m 1200

max_prepared_transactions

PREPARE TRANSACTIONコマンドによって準備状態になれるトランザクションの最大数を決定します。この値は通常、max_connectionsの値と同じか、それ以上に設定する必要があります。各トランザクションは600バイトの共有メモリを消費します。

# 現在の設定値を確認
gpconfig -s max_prepared_transactions

# 設定を変更
gpconfig -c max_prepared_transactions -v 300

max_files_per_process

各サーバープロセスが同時に開くことができるファイルの最大数を設定します。デフォルトは1000です。この値はサーバーの起動時にのみ設定できます。

# 現在の設定値を確認
gpconfig -s max_files_per_process

# 設定を変更
gpconfig -c max_files_per_process -v 2000

3. その他の重要なパラメータ

shared_buffers

ディスクI/Oのために使用される共有メモリバッファのサイズです。この値は、セグメントノードでのみ設定できます。開始時は物理メモリの15%程度から設定し、パフォーマンスの向上とスワップの発生を監視しながら段階的に増やしていくことを推奨します。

# 現在の設定値を確認
gpconfig -s shared_buffers

# 設定を変更
gpconfig -c shared_buffers -v 2048MB

temp_buffers

各データベースセッションが一時データに使用するメモリの量です。デフォルトは1MBですが、大規模な一時テーブルを扱う際のパフォーマンス向上に役立ちます。

# 現在の設定値を確認
gpconfig -s temp_buffers

# 設定を変更
gpconfig -c temp_buffers -v 8192MB

fts_probe_threadcount

ftsprobeスレッドの数を設定します。この値は、各サーバー上のセグメント数以上に設定することが推奨されます。

# 現在の設定値を確認
gpconfig -s fts_probe_threadcount

# 設定を変更
gpconfig -c fts_probe_threadcount -v 32

設定の適用

パラメータを変更した後、データベースを再起動するか、設定を再読み込みする必要があります。

# 設定を再読み込み
gpstop -u

トラブルシューティングのケーススタディ

GreenPlumクラスタで大規模なデータをクエリする際に、クエリの実行中にセグメントがクラッシュし、接続が切断される問題が発生しました。

ERROR 58000: out of memory
DETAIL:  segment-2 could not allocate additional memory for query execution

マスターノードのログを確認すると、以下のメッセージが記録されていました。

seg-2: FATAL:  out of memory for sort operation

この問題は、メモリ関連のパラメータが最適化されていないことが原因であると判断されました。

1. メモリ不足の確認: サーバーの物理メモリを確認し、十分な量であることを確認しました。
2. パラメータの調査: statement_mem、vmem_protect_limit、およびsort_memのパラメータを調査しました。これらのパラメータがデフォルト値のまま設定されており、大規模なクエリの実行に不十分であることが判明しました。
3. パラメータの調整: sort_memを256MB、statement_memを512MB、vmem_protect_limitを16GBに増やしました。
4. データベースの再起動: 変更を適用するためにデータベースを再起動しました。

これらの調整後、大規模なクエリも正常に実行されるようになり、問題は解決しました。このケースは、メモリパラメータの適切なチューニングがシステムの安定性とパフォーマンスに与える影響を示しています。