GreenPlumのパフォーマンスのチューニングを1回記録
15012 ワード
配備されたGreenPlumクラスタでデータ照会を行うと,データ量が大きくなるとクエリが走り中断し,あるsegmentが接続を中断したことを示す.
masterのpg_を表示するlogのログ:
簡単な分析を経て、メモリ関連パラメータが最適化されていないことが推測されます.同じSQLクエリは時間間隔が小さいので、すぐに結果が出ます.では、2つの側面から始めましょう.
1.サーバのメモリが不足し、segmentがインタラクションを中断しました.
2.データベース・パラメータの設定が不合理で、それほど多くのメモリが使用できません.
最初の質問:
1)まず,仮想マシンのメモリを調べたところ,8 Gしかなく,少し少ないと感じ,32 Gに加算したが,まだ前の問題が発生している.
2)では,システム設定がメモリの使用を制限しているのではないかと推測する.次のように使用します.
prctl -n project.max-shm-memory -i project default
prctl -n project.max-sem-ids -i project default
対応する設定を確認しましたが、変更する必要はありません.これにより、システムのボトルネックを排除し、次にデータベースを表示できます.
1)masterノードのpostgresqlを直接開く.confファイルは構成を表示し、shared_を発見します.buffersおよびすべてのパラメータはデフォルト値であり、最適化後.データベースの再起動には、まだ上記の問題があります.
2)max_の表示statement_mem、statement_mem、gp_vmem_protect_Limitの3つのパラメータは、masterに設定されていないことがわかり、ここで問題があると推定されます.
3)gpconfig-s statement_を使用memエラーが表示され、ノードに接続を中断するように要求されます.このエラーレポートの非常に卵が痛くて、考えが混同して、データノードが間違っていると思っています.
4)gp_を確定するvmem_protect_limitパラメータ、発見は8 GBで、完全に十分です.一時停滞に陥り、資料やセリフのプロファイルを調べたところ、statement_memパラメータがconfファイルにない場合は、デフォルト値である可能性が高いので、一歩進みます.
5)データベースを開き、select*from gp_を実行settings; データベースのすべての構成を表示し、statement_を発見します.memパラメータはデフォルトの128 MBなので、問題は間違いありません.
6)gpconfigクエリーパラメータが失敗したため,gpconfigを用いてパラメータを設定しようとせず,各ノードの値を手動で変更した.データベースを再起動した後、問題の解決に成功しました.
後でpgconfig-c statement_mem-v 2 GBはパラメータを設定できることを発見しました.-sがクエリーに来たときにエラーを報告しました.rlg、そんなにたくさんのファイルを手動で変更しても簡単にできます・・・
Greenplumパラメータ構成の最適化:
クエリー・パラメータ
パラメータ設定コマンドの変更
work_mem
work_mem(,global,物理メモリの2%-4%)は、segmentがsortとして使用され、hash操作のメモリサイズPostgreSQLが大きなテーブルをソートすると、データベースはこのパラメータに従ってサイズを指定してスライスソートし、中間結果を一時ファイルに格納し、これらの中間結果の一時ファイルは最終的に再びソートされるので、このパラメータを増やすことで一時ファイルの個数を減らし、ソート効率を向上させることができます.もちろん、設定が大きすぎるとswapが発生するので、このパラメータを設定するときは慎重にしてください.
mainteance_work_mem(
global,CREATE INDEX,VACUMなどの場合に使用され,segmentはVACUM,CREATE INDEXなどの操作のメモリサイズに使用され,デフォルトは16メガバイト(16 MB)である.1つのデータベース・セッションでは、任意の時点で1つの操作しか実行できないため、1つのデータベース・インストールでは通常、このような作業が同時に実行されることは多くありません.この数値をworkよりも多く設定します.memがもっと大きいのは安全です.より大きな設定により、データベースのダンプのクリーンアップとリカバリの速度が向上します.
max_statement_mem
クエリーごとに最大使用メモリ量を設定します.このパラメータはstatement_を防止します.memパラメータの設定メモリが大きすぎるためメモリがオーバーフローする.
statement_mem
各クエリーがsegmentホストで使用可能なメモリを設定します.このパラメータ設定の値はmax_を超えてはいけません.statement_mem設定の値は、リソースキューが構成されている場合、リソースキュー設定の値を超えてはいけません.
gp_vmem_protect_limit
各segmentデータベースが実行するすべてのクエリーに割り当てられるメモリの合計量を制御します.クエリに必要なメモリがこの値を超えると、失敗します.
gp_workfile_limit_files_per_query
SQLクエリに割り当てられたメモリが不足している場合、Greenplumデータベースはオーバーフローファイル(ワークファイルとも呼ばれる)を作成します.デフォルトでは、SQLクエリーで最大10,000個のオーバーフローファイルを作成できます.これは、ほとんどのクエリーを満たすのに十分です.このパラメータは、1つのクエリーで最大数のオーバーフローファイルを作成できるかどうかを決定します.0は制限がないことを意味します.オーバーフローファイルデータを制限することで、制御不能なクエリーがシステム全体を破壊することを防止できます.
gp_statement_mem
サーバ構成パラメータgp_statement_memは、セグメント・データベース上の単一クエリーで使用できるメモリの合計量を制御します.文がより多くのメモリを必要とする場合、データはディスクにオーバーフローします.
effective_cache_size
(masterノード、物理メモリの85%に設定できます)このパラメータは、PostgreSQLのオプティマイザがデータをキャッシュするために使用できるメモリの数と、インデックスを使用するかどうかを決定するのに役立ちます.この値が大きいほど、オプティマイザがインデックスを使用する可能性も高くなります.この値はshared_に設定する必要がありますbuffersに使用可能なオペレーティングシステムキャッシュの合計を加えます.通常、この値はシステムメモリの総量の50%以上を超えます.
gp_resqueue_priority_cpucores_per_segment
masterと各segmentの使用可能なcpu個数、各segmentの割り当てスレッド数;
max_connections
最大接続数は、SegmentがMasterの5～10倍に設定することを推奨します.max_connections = 200 #(master、standby)max_connections = 1200 #(segment)
max_prepared_transactions
このパラメータは、データベースの起動時にのみ設定できます.同時にprepared状態にあるトランザクションの最大数を決定します(PREPARE TRANSACTIONコマンドを参照).値が0に設定されている場合.データベースはpreparedトランザクションのプロパティを閉じます.通常、その値はmax_と一致するはずです.connectionsの値は同じです.トランザクションごとに600バイト(b)の共有メモリが消費されます.
max_files_per_process
各サーバ・プロセスで同時に開くことができる最大ファイル数を設定します.デフォルトは1000です.カーネルが合理的なプロセスごとの制限を強制する場合は、この設定を心配する必要はありません.しかし、一部のプラットフォーム(特にほとんどのBSDシステム)では、カーネルは、独立したプロセスがシステムが本当にサポートできる数よりも多くのファイルを開くことを可能にします.「Too many open files」のような失敗が見つかった場合は、この設定を縮小してみましょう.この値は、サーバが起動したときにのみ設定できます.
shared_buffers
segmentノードのみを構成して、ディスクの読み書きのメモリバッファとして使用し、総メモリの15%などの小さな値を設定してから、徐々に増加し、パフォーマンスの向上とswapの状況を監視することができます.
temp_buffers:つまりテンポラリ・バッファであり、データベース・アクセスのテンポラリ・データを持ち、GPのデフォルト値は1 Mであり、比較的大きなテンポラリ・テーブルにアクセスする際にパフォーマンスの向上に役立ちます.
gp_fts_probe_threadcount:
ftsprobeスレッド数を設定します.このパラメータは、各サーバsegmentsの数以上を推奨します.
パラメータを有効にするには、データベースを再起動します.
転載先:https://www.cnblogs.com/kuang17/p/9968415.html
ERROR 58M01 "Error on receive from seg0 slice1 192.168.110.84:6000 pid=xxx: server closed the connection unexpectedly"
This probably means the server terminated abnormally before or while processing the request
masterのpg_を表示するlogのログ:
seg-1 could not connect to segment: initalization of segwork group failed (cdbgang.c:237)
簡単な分析を経て、メモリ関連パラメータが最適化されていないことが推測されます.同じSQLクエリは時間間隔が小さいので、すぐに結果が出ます.では、2つの側面から始めましょう.
1.サーバのメモリが不足し、segmentがインタラクションを中断しました.
2.データベース・パラメータの設定が不合理で、それほど多くのメモリが使用できません.
最初の質問:
1)まず,仮想マシンのメモリを調べたところ,8 Gしかなく,少し少ないと感じ,32 Gに加算したが,まだ前の問題が発生している.
2)では,システム設定がメモリの使用を制限しているのではないかと推測する.次のように使用します.
prctl -n project.max-shm-memory -i project default
prctl -n project.max-sem-ids -i project default
対応する設定を確認しましたが、変更する必要はありません.これにより、システムのボトルネックを排除し、次にデータベースを表示できます.
1)masterノードのpostgresqlを直接開く.confファイルは構成を表示し、shared_を発見します.buffersおよびすべてのパラメータはデフォルト値であり、最適化後.データベースの再起動には、まだ上記の問題があります.
2)max_の表示statement_mem、statement_mem、gp_vmem_protect_Limitの3つのパラメータは、masterに設定されていないことがわかり、ここで問題があると推定されます.
3)gpconfig-s statement_を使用memエラーが表示され、ノードに接続を中断するように要求されます.このエラーレポートの非常に卵が痛くて、考えが混同して、データノードが間違っていると思っています.
4)gp_を確定するvmem_protect_limitパラメータ、発見は8 GBで、完全に十分です.一時停滞に陥り、資料やセリフのプロファイルを調べたところ、statement_memパラメータがconfファイルにない場合は、デフォルト値である可能性が高いので、一歩進みます.
5)データベースを開き、select*from gp_を実行settings; データベースのすべての構成を表示し、statement_を発見します.memパラメータはデフォルトの128 MBなので、問題は間違いありません.
6)gpconfigクエリーパラメータが失敗したため,gpconfigを用いてパラメータを設定しようとせず,各ノードの値を手動で変更した.データベースを再起動した後、問題の解決に成功しました.
後でpgconfig-c statement_mem-v 2 GBはパラメータを設定できることを発見しました.-sがクエリーに来たときにエラーを報告しました.rlg、そんなにたくさんのファイルを手動で変更しても簡単にできます・・・
Greenplumパラメータ構成の最適化:
クエリー・パラメータ
gpconfig --show max_connectionsパラメータ設定コマンドの変更
gpconfig-c <parameter name> -v <parameter value> ：gpconfig-c log_statement -v DDL gpconfig -r <parameter name> work_mem
work_mem(,global,物理メモリの2%-4%)は、segmentがsortとして使用され、hash操作のメモリサイズPostgreSQLが大きなテーブルをソートすると、データベースはこのパラメータに従ってサイズを指定してスライスソートし、中間結果を一時ファイルに格納し、これらの中間結果の一時ファイルは最終的に再びソートされるので、このパラメータを増やすことで一時ファイルの個数を減らし、ソート効率を向上させることができます.もちろん、設定が大きすぎるとswapが発生するので、このパラメータを設定するときは慎重にしてください.
gpconfig -s work_mem
Values on all segments are consistent
GUC : work_mem
Master value: 32MB
Segment value: 32MB
gpconfig -c work_mem -v 128MB
：SET work_mem TO '64MB' ： gpadmin-[INFO]:-completed successfully with parameters mainteance_work_mem(
global,CREATE INDEX,VACUMなどの場合に使用され,segmentはVACUM,CREATE INDEXなどの操作のメモリサイズに使用され,デフォルトは16メガバイト(16 MB)である.1つのデータベース・セッションでは、任意の時点で1つの操作しか実行できないため、1つのデータベース・インストールでは通常、このような作業が同時に実行されることは多くありません.この数値をworkよりも多く設定します.memがもっと大きいのは安全です.より大きな設定により、データベースのダンプのクリーンアップとリカバリの速度が向上します.
gpconfig -s maintenance_work_mem
GUC : maintenance_work_mem
Master value: 64MB
Segment value: 64MB gpconfig -c maintenance_work_mem -v 256MB max_statement_mem
クエリーごとに最大使用メモリ量を設定します.このパラメータはstatement_を防止します.memパラメータの設定メモリが大きすぎるためメモリがオーバーフローする.
gpconfig -s max_statement_mem
Values on all segments are consistent
GUC : max_statement_mem
Master value: 2000MB Segment value: 2000MB gpconfig -c max_statement_mem -v 2000MB statement_mem
各クエリーがsegmentホストで使用可能なメモリを設定します.このパラメータ設定の値はmax_を超えてはいけません.statement_mem設定の値は、リソースキューが構成されている場合、リソースキュー設定の値を超えてはいけません.
gpconfig -s statement_mem
Values on all segments are consistent
GUC : statement_mem
Master value: 125MB Segment value: 125MB gpconfig -c statement_mem -v 256MBgp_vmem_protect_limit
各segmentデータベースが実行するすべてのクエリーに割り当てられるメモリの合計量を制御します.クエリに必要なメモリがこの値を超えると、失敗します.
gpconfig -s gp_vmem_protect_limit
Values on all segments are consistent
GUC : gp_vmem_protect_limit
Master value: 8192 Segment value: 8192gp_workfile_limit_files_per_query
SQLクエリに割り当てられたメモリが不足している場合、Greenplumデータベースはオーバーフローファイル(ワークファイルとも呼ばれる)を作成します.デフォルトでは、SQLクエリーで最大10,000個のオーバーフローファイルを作成できます.これは、ほとんどのクエリーを満たすのに十分です.このパラメータは、1つのクエリーで最大数のオーバーフローファイルを作成できるかどうかを決定します.0は制限がないことを意味します.オーバーフローファイルデータを制限することで、制御不能なクエリーがシステム全体を破壊することを防止できます.
gpconfig -s gp_workfile_limit_files_per_query
Values on all segments are consistent
GUC : gp_workfile_limit_files_per_query
Master value: 100000 Segment value: 100000gp_statement_mem
サーバ構成パラメータgp_statement_memは、セグメント・データベース上の単一クエリーで使用できるメモリの合計量を制御します.文がより多くのメモリを必要とする場合、データはディスクにオーバーフローします.
effective_cache_size
(masterノード、物理メモリの85%に設定できます)このパラメータは、PostgreSQLのオプティマイザがデータをキャッシュするために使用できるメモリの数と、インデックスを使用するかどうかを決定するのに役立ちます.この値が大きいほど、オプティマイザがインデックスを使用する可能性も高くなります.この値はshared_に設定する必要がありますbuffersに使用可能なオペレーティングシステムキャッシュの合計を加えます.通常、この値はシステムメモリの総量の50%以上を超えます.
：
gpconfig -s effective_cache_size
Values on all segments are consistent
GUC : effective_cache_size
Master value: 512MB Segment value: 512MB gpconfig -c effective_cache_size -v 40960MBgp_resqueue_priority_cpucores_per_segment
masterと各segmentの使用可能なcpu個数、各segmentの割り当てスレッド数;
gpconfig -s gp_resqueue_priority_cpucores_per_segment
Values on all segments are consistent
GUC : gp_resqueue_priority_cpucores_per_segment
Master value: 4 Segment value: 4 gpconfig -s checkpoint_segments gpconfig -c gp_resqueue_priority_cpucores_per_segment -v 8max_connections
最大接続数は、SegmentがMasterの5～10倍に設定することを推奨します.max_connections = 200 #(master、standby)max_connections = 1200 #(segment)
：
gpconfig -s max_connections
GUC : max_connections
Master value: 250
Segment value: 750 gpconfig -c max_connections -v 1200 -m 300max_prepared_transactions
このパラメータは、データベースの起動時にのみ設定できます.同時にprepared状態にあるトランザクションの最大数を決定します(PREPARE TRANSACTIONコマンドを参照).値が0に設定されている場合.データベースはpreparedトランザクションのプロパティを閉じます.通常、その値はmax_と一致するはずです.connectionsの値は同じです.トランザクションごとに600バイト(b)の共有メモリが消費されます.
：
gpconfig -s max_prepared_transactions
Values on all segments are consistent
GUC : max_prepared_transactions
Master value: 250 Segment value: 250 gpconfig -c max_prepared_transactions -v 300 max_files_per_process
各サーバ・プロセスで同時に開くことができる最大ファイル数を設定します.デフォルトは1000です.カーネルが合理的なプロセスごとの制限を強制する場合は、この設定を心配する必要はありません.しかし、一部のプラットフォーム(特にほとんどのBSDシステム)では、カーネルは、独立したプロセスがシステムが本当にサポートできる数よりも多くのファイルを開くことを可能にします.「Too many open files」のような失敗が見つかった場合は、この設定を縮小してみましょう.この値は、サーバが起動したときにのみ設定できます.
：
gpconfig -s max_files_per_process
Values on all segments are consistent
GUC : max_files_per_process
Master value: 1000 Segment value: 1000 gpconfig -c max_files_per_process -v 1000 shared_buffers
segmentノードのみを構成して、ディスクの読み書きのメモリバッファとして使用し、総メモリの15%などの小さな値を設定してから、徐々に増加し、パフォーマンスの向上とswapの状況を監視することができます.
gpconfig -s shared_buffers
Values on all segments are consistent
GUC : shared_buffers
Master value: 64MB Segment value: 125MB gpconfig -c shared_buffers -v 1024MB gpconfig -r shared_buffers -v 1024MB temp_buffers:つまりテンポラリ・バッファであり、データベース・アクセスのテンポラリ・データを持ち、GPのデフォルト値は1 Mであり、比較的大きなテンポラリ・テーブルにアクセスする際にパフォーマンスの向上に役立ちます.
：
gpconfig -s temp_buffers
Values on all segments are consistent
GUC : temp_buffers
Master value: 1024 Segment value: 1024 gpconfig -c temp_buffers -v 4096 gp_fts_probe_threadcount:
ftsprobeスレッド数を設定します.このパラメータは、各サーバsegmentsの数以上を推奨します.
：
gpconfig -s gp_fts_probe_threadcount
Values on all segments are consistent
GUC : gp_fts_probe_threadcount
Master value: 16 Segment value: 16 パラメータを有効にするには、データベースを再起動します.
gpstop -u postgresql.conf pg_hba.conf転載先:https://www.cnblogs.com/kuang17/p/9968415.html