Testing and tuning PGD clusters#
次のアプローチを使用してPGDアプリケーションをテストできます。
pgd_bench#
Postgresベンチマークアプリケーション pgbench は、新しいアプリケーションpgd_benchの形式で拡張されました。
pgd_bench は、PostgreSQL binディレクトリに追加される通常のコマンドラインユーティリティです。このユーティリティは、PostgreSQL pgbenchツールに基づいていますが、 CAMOトランザクションとPGD固有のワークロードのベンチマークをサポートしています。
pgd_benchの機能はpgbench機能のスーパーセットですが、正常に動作するにはBDR拡張機能をインストールする必要があります。
主な違いは次のとおりです。
特定の場合にグローバルロックタイムアウトを防ぐための標準のpgbenchシナリオでの初期化
-iフラグを調整。標準シナリオの
VACUUMコマンドは、すべてのノードで実行されます。pgd_benchリリースはBDR拡張機能のリリースに関連付けられ、対応するPostgresディストリビューションに対してビルドされます。この情報は、
--versionフラグの出力に反映されます。
現在のバージョンでは、 CAMOまたは通常のPGD展開を使用しながらフェールオーバーテストを実行できます。
次のオプションが追加されました。
- m, --mode=regular|camo|failover
mode in which pgbench should run (default: regular)
-m camoまたは-m failoverを使用して、pgd_benchのモードを指定します。-m failover仕様を使用して、通常のPGD展開でフェイルオーバーをテストできます。
- -retry
retry transactions on failover
--retryを使用して、-m failoverモードでフェイルオーバーが発生したときにトランザクションをリトライするかどうかを指定します。このオプションは-m camoモードではデフォルトで有効になっています。
これらのオプションに加えて、 DSNform でフェイルオーバーのピアノードに関する接続情報を指定する必要があります。
次に、 CAMO環境の例を示します。
pgd_bench -m camo -p $node1_port -h $node1_host bdrdemo \
"host=$node2_host user=postgres port=$node2_port dbname=bdrdemo"
このコマンドはCAMOモードで実行されます。ノード1に接続し、テストを実行します。ノード1への接続が失われると、pgd_benchはノード2に接続します。ノード2を照会して、進行中のトランザクションのステータスを取得します。中止されたトランザクションおよび進行中のトランザクションは、 CAMOモードで再試行されます。
フェイルオーバーモードで--retry
を指定すると、進行中のトランザクションが再試行されます。このシナリオでは、進行中のトランザクションのステータスを見つける方法はありません。
pgd_benchの使用に関する注意事項#
カスタムinitスクリプトを使用する場合、 DDLコマンドの背後にある意味を理解することが重要です。通常、
CREATE INDEXなどのDDL操作を続行する前に、セカンダリノードがデータのロード手順に追いつくのを待機することをお勧めします。後者は、データのロードが完了するまで取得できないグローバルロックを取得するため、タイムアウトになる可能性があります。PostgreSQLおよび/またはBDR拡張機能を含む考えられる拡張機能によって発行される
NOTICEおよびWARNINGメッセージなどのクライアントメッセージを抑制するために追加の手順は実行されません。client_min_messages、bdr.camo_enable_client_warningsなどの適切な変数を設定してそれらを抑制するのはあなたの責任です。pgd_benchは、カスタムスクリプトのSQLトランザクションを開始しません。 SQLトランザクションで実行するスクリプトには、transaction startおよびendコマンドを含める必要があります。
-m/--modeオプションをcamoに設定してpgd_benchが実行された場合、提供されるカスタムスクリプトはSQLコマンドをトランザクションでラップする必要があります。そうしないと、 CAMO機能が予想通りに動作しません。
パフォーマンスのテストとチューニング#
PGDを使用すると、マルチプルのノードに書き込みトランザクションを発行できます。これらの書き込みを各ノードに戻すと、パフォーマンスのコストが発生します。
第一に、別のノードからの変更の再生には、CPUコストとI/Oコストが発生し、WALレコードが生成されます。 SQLを再実行する必要がないため、CPUオーバーヘッドが低いため、通常、リソースの使用量は元のトランザクションよりも少なくなります。 UPDATEおよびDELETEトランザクションの場合、データがキャッシュされていない場合、再生時にI/Oコストが発生する可能性があります。
次に、変更の再生は、テーブルレベルおよび行レベルのロックを保持するため、ローカルワークロードに対する競合を生成する可能性があります。競合のないレプリケートデータ型CRDTと列レベルの競合検出CLCD機能は、同時更新の場合でも正しい回答を取得しますが、通常のロックオーバーヘッドは削除されません。ロック競合が発生した場合は、競合する更新を回避するか、トランザクションをできるだけ短くしてください。大規模なトランザクションで頻繁に更新された行は、そのトランザクションのパフォーマンスのボトルネックを発生させます。複雑なアプリケーションでは、スケーラビリティを維持するためにいくつかの考慮が必要です。
パフォーマンスに問題があると思われる場合は、ベンチマークツールを使用してパフォーマンステストを開発します。 pgd_benchを使用すると、ユースケースに固有のカスタムテストスクリプトを作成できるため、 SQLのオーバーヘッドを理解し、同時実行の影響を測定できます。
PGDの実行が遅い場合、次のことをお勧めします。
実稼働システムの問題ケースにできる限り近づけて、 pgd_benchのカスタムテストスクリプトを作成します。
1つのノードでスクリプトを実行して、ベースライン図を取得します。
1つのノードで実行したのと同じ合計数のセッションを使用して、運用環境で発生するのと同じ数のノードでスクリプトを実行します。このテクニックは、複数のノードに移動した効果を示します。
これらの2つのテストのセッション数を増やして、アプリケーションでの競合の増加による影響をプロットできます。
テストがレプリケーションの遅延を考慮して十分な長さであることを確認します。
テスト中にレプリケーション遅延が増加していないことを確認します。
通常のPostgresチューニング機能をすべて使用して、アプリケーションの重要な部分の速度を向上させます。