このドキュメントでは、OLTP ベンチマーク仕様である TPC-C を使用して AlloyDB のパフォーマンスをベンチマークするために、AlloyDB for PostgreSQL とクライアント マシンを構成する方法について説明します。このドキュメントでは、インデックス挿入のみや選択のみなど、読み取りと書き込みの負荷が高い OLTP シナリオをカスタマイズして実行する方法についても説明します。
このドキュメントの手順は、AlloyDB とクライアント マシンの特定の構成に基づいています。ベンチマークの手順の各ステップで、指定された値を使用します。
AlloyDB ワークロード機能
AlloyDB は、すべてのビジネスと重要なワークロードに適したエンタープライズ レベルの信頼性、スケーラビリティ、パフォーマンスを提供します。AlloyDB には、トランザクション（OLTP）、分析（OLAP）、ハイブリッド（HTAP）ワークロードの高パフォーマンスを実現する次のコンポーネントと機能が用意されています。
- ログとトランザクションの管理
- 動的メモリ管理
- 人工知能と ML の統合
- 組み込みのカラム型エンジン
- マルチティア キャッシュ
- 分散型スケーラブル ストレージ
リレーショナル データベース システムでは通常、データベース管理者がベンチマーク用にデータベースを最適化する必要があります。これには、トランザクション ログの設定の構成、適切なバッファプール サイズの確立、他のデータベース パラメータやフラグと特性の変更が含まれます。これらの設定は、インスタンスのサイズとタイプによって異なります。
AlloyDB には、各マシンタイプに最適化された設定が事前構成されています。AlloyDB では、高い OLTP パフォーマンスを実現するためにデータベース レベルでフラグをチューニングする必要はありません。AlloyDB には高い OLTP パフォーマンスが組み込まれています。
サポートされているベンチマーク タイプ
このドキュメントでは、次のツールを使用して OLTP ベンチマークを実行する方法について説明します。
| OLTP ベンチマーク ドライバ | ユースケース |
|---|---|
| HammerDB | HammerDB は、1 分あたりのトランザクション数（TPM）でシステムのパフォーマンスを測定し、詳細な統計情報とパフォーマンス指標を含むレポートを生成します。 HammerDB は、ベンチマーク パラメータのカスタマイズをサポートしています。これにより、データベースのサイズ、倉庫の数、その他のワークロード特性を調整して、さまざまなシナリオをシミュレートできます。 HammerDB には、OLTP システムのパフォーマンスを評価するための TPC-C ベンチマーク実装が含まれています。HammerDB TPC-C 実装を使用すると、卸売サプライヤー環境の動作を模倣するトランザクションの組み合わせなど、TPC-C ベンチマークに似たワークロードをシミュレートできます。 |
| pgbench | pgbench は、PostgreSQL にバンドルされているベンチマーク ツールです。pgbench を使用すると、データの挿入、更新、選択などのトランザクション ワークロードをシミュレートし、データベース システムのパフォーマンスをトランザクション / 秒（TPS）で測定できます。 pgbench を使用すると、データベースのサイズ、クライアントの数、トランザクションの組み合わせをカスタマイズして本番環境ワークロードをエミュレートし、さまざまなシナリオでのシステムの動作に関する分析情報を取得できます。 pgbench には TPC-B の実装が含まれています。pgbench TPC-B の実装は TPC-B ベンチマークに似ています。 |
始める前に
- Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
-
AlloyDB for PostgreSQL の作成と接続に必要な Cloud API を有効にします。
[プロジェクトを確認] の手順で、[次へ] をクリックして、変更するプロジェクトの名前を確認します。
[API を有効にする] の手順で、[有効にする] をクリックして、次の機能を有効にします。
- AlloyDB API
- Compute Engine API
- Cloud Resource Manager API
- Service Networking API
AlloyDB と同じ Google Cloud プロジェクトにある VPC ネットワークを使用して AlloyDB へのネットワーク接続を構成する場合は、Service Networking API が必要です。
別の Google Cloud プロジェクトに存在する VPC ネットワークを使用して AlloyDB へのネットワーク接続を構成する場合は、Compute Engine API と Cloud Resource Manager API が必要です。
データベースとクライアント マシンを設定してプロビジョニングする
AlloyDB クラスタとインスタンスを作成して、ベンチマークを開始します。特に明記されていない限り、このドキュメントの情報は、プライマリ AlloyDB インスタンスとして 128 GB RAM の 16 vCPU に基づいています。
AlloyDB クラスタとインスタンスを作成する
[クラスタ] ページに移動します。
[クラスタを作成] をクリックします。
[クラスタ ID] フィールドに、クラスタの名前を入力します。
[ゾーンの可用性] で、クラスタタイプに [複数のゾーン（高可用性）] を選択します。
デフォルトのネットワークを選択します。
[データベースのバージョン] フィールドで、[PostgreSQL 15] を選択します。
プライマリ ゾーンの場所とプライベート IP アドレスをメモします。読み取りプールは作成しないでください。
[クラスタを作成] をクリックします。
クライアント マシンをプロビジョニングする
OLTP ベンチマークを実行するには、十分な処理能力を持つクライアント マシンが必要です。HammerDB や pgbench などのベンチマーク ツールは高度な並列処理で実行され、CPU を大量に消費します。OLTP ベンチマークを実行する際、クライアント マシンがボトルネックにならないようにする必要があります。
特に明記しない限り、このドキュメントの手順では、128 GB ディスク搭載の E2-standard-32 マシンを OLTP ベンチマークのクライアントとして使用し、128 GB RAM 搭載の 16 vCPU マシンで AlloyDB インスタンスを駆動します。クライアント マシンは、AlloyDB プライマリ インスタンスと同じゾーンに作成する必要があります。
16 個の仮想 CPU を持つ AlloyDB プライマリ インスタンスで TPC-C ベンチマークを実行するには、次の手順で Compute Engine VM を作成し、クライアント マシンをプロビジョニングします。
Google Cloud コンソールで [VM インスタンス] ページに移動します。
- 接続する AlloyDB インスタンスを含むプロジェクトを選択します。
- [インスタンスを作成] をクリックします。
- [マシンの構成] セクションをクリックします。
- インスタンスの名前を入力します。
- インスタンスを作成するゾーンを構成します。ゾーンは、AlloyDB プライマリ インスタンスのゾーンと同じにする必要があります。
- マシンタイプとして e2-standard-32 を選択します。
- [OS and Storage] セクションのデフォルト値は変更しません。
- [ネットワーキング] セクションをクリックし、[ネットワーク インターフェース] を、AlloyDB へのプライベート サービス アクセス用に構成された VPC ネットワークに設定します。
[ネットワーク インターフェース] がプライベート サービス アクセス用に構成された VPC ネットワークに設定されていない場合は、展開して [ネットワーク] を VPC ネットワークに設定します。 - [オブザーバビリティ] セクションのデフォルト値はそのままにします。
- [セキュリティ] セクションをクリックします。
- [ID と API へのアクセス] で [アクセス スコープ] を [すべての Cloud API に完全アクセス権を許可] に設定します。
- [詳細] セクションはデフォルト値のままにします。
- [作成] をクリックします。
- VM の作成後、SSH を使用して作成した Compute Engine VM に接続します。
ベンチマーク ドライバマシンを設定する
データベースとクライアント マシンをインストールして設定したら、 Google Cloudで実行されているクライアント マシンを構成します。ここで、HammerDB や pgbench などのベンチマーク ツールをインストールします。
ベンチマーク ドライバマシンを設定する手順は次のとおりです。
次の
gcloud compute sshコマンドを使用してクライアント マシンに接続します。gcloud compute ssh --zone "PRIMARY_ZONE" "CLIENT_MACHINE_NAME" --project "GOOGLE_PROJECT"PostgreSQL クライアントをインストールします。
次のコマンドを使用して、psql アプリケーションを含む PostgreSQL クライアントをインストールし、接続できることを確認します。
sudo apt-get update sudo apt install postgresql-client次のコマンドを使用して、クライアントが機能し、AlloyDB に接続できることを確認します。プライマリ AlloyDB インスタンスのプライベート IP アドレスを使用します。
psql -h PRIVATE_IP -U postgres
次のコマンドを実行して、TPC-C ベンチマーク用の HammerDB-4.6 ドライバをインストールします。
mkdir hammerdb pushd hammerdb curl -OL https://github.com/TPC-Council/HammerDB/releases/download/v4.6/HammerDB-4.6-Linux.tar.gz tar zxvf HammerDB-4.6-Linux.tar.gz次のコマンドを実行して、TPC-B とその他の OLTP ベンチマーク用の pgbench ドライバをインストールします。
sudo apt-get update sudo apt-get install postgresql-contrib pgbench --versionpgbench --versionがエラーなしで実行された場合、pgbench がインストールされていることを意味します。
ベンチマークのクリーンアップを実行する
複数のベンチマークを連続して実行する場合は、ベンチマーク間のベンチマークのクリーンアップを実行して、正確で信頼性の高いベンチマーク結果を確保する必要があります。
ベンチマークのクリーンアップを行うと、以前のベンチマークの残留効果が新しいベンチマークのパフォーマンス測定に影響しないようにすることができます。ベンチマークのクリーンアップは、ベンチマーク結果の一貫性と再現性の確保にも役立ちます。これは、さまざまなシステム間の有意な比較を行う場合や、ハードウェア、ソフトウェア、構成の最適化の余地を特定する場合に不可欠です。
別のベンチマークを実行する前に、次の手順でベンチマークのクリーンアップを行います。
以前のベンチマーク データまたはベンチマーク データベースを削除します。以前のベンチマーク データベースを削除するには、クライアント マシンから次の
psqlコマンドを使用します。psql -h PRIVATE_IP -U postgres -c "DROP DATABASE IF EXISTS <database_name>;"psqlの使用方法については、データベースに接続するをご覧ください。AlloyDB インスタンスを再起動します。この手順では、データベースとオペレーティング システム レベルでキャッシュが削除されます。
TPC-C ベンチマークを実行する
HammerDB は、OLTP システムのパフォーマンスを評価するための TPC-C ベンチマーク実装を含むベンチマーク ツールです。HammerDB の TPC-C 実装を使用すると、卸売サプライヤー環境の動作を模倣するトランザクションの組み合わせなど、TPC-C ベンチマークに似たワークロードをシミュレートできます。
HammerDB は、1 分あたりのトランザクション数（TPM）でシステムのパフォーマンスを測定し、詳細な統計情報とパフォーマンス指標を含むレポートを生成します。さらに、HammerDB はベンチマーク パラメータのカスタマイズをサポートしているため、ユーザーはデータベースのサイズ、倉庫の数、その他のワークロード特性を調整して、さまざまなシナリオをシミュレートできます。
パフォーマンス評価のシナリオ
TPC-C ベンチマークのパフォーマンスは、次の方法で評価されます。
部分的にキャッシュに保存する（約 30%）モード: このモードでは、大規模な TPC-C データベースが生成されますが、バッファ キャッシュに収まるのは一部のみです。このモードでは、トランザクションがメモリから提供されない場合があり、基盤となるストレージ サブシステムへの I/O が発生します。このシナリオは、多くのユーザーの OLTP ニーズに適用されます。
完全に（100%）キャッシュに保存されるモード: このモードでは、TPC-C データベースがバッファ キャッシュに完全に収まります。AlloyDB インスタンスは、バッファ キャッシュを含む 128 GB の使用可能な RAM の約 90% を使用しています。
TPC-C トランザクションは、読み取りがほとんどバッファ キャッシュから提供されるため、I/O を最小限に抑えるため、このモードでは、部分的にキャッシュに保存された実行と比較して TPM が高くなることが予想されます。このシナリオは、I/O 要件が非常に低いユーザーの OLTP ニーズに適用されます。
クライアント マシンを設定する
複数のベンチマークを連続して実行する場合は、ベンチマークのクリーンアップを行います。
次のコマンドを実行して
hammerdb/HammerDB-4.6 directoryを開きます。cd hammerdb/HammerDB-4.6このディレクトリからコマンドを実行して、クライアント マシンを設定します。
次のコマンドを使用して
setup.envファイルを作成します。cat << EOF > setup.env# Private IP of the AlloyDB primary instance export PGHOST=PRIVATE_IP# Postgres default port address. You do not need to change it unless you use non-default port address. export PGPORT=5432 # default port to connect with postgres# Number of TPC-C warehouses to load. This determines the overall database size. export NUM_WAREHOUSE=576# Number of users for running the benchmark. export NUM_USERS=256 EOF生成された
setup.envファイルを編集し、ハイライト表示されたパラメータ値をすべて、環境の設定に最適なパラメータ値に置き換えます。省略可:
setup.envファイルでNUM_WAREHOUSEを3200に変更して、部分的にキャッシュに保存されるモード（約 30%）をテストします。詳細については、パフォーマンス評価のシナリオをご覧ください。省略可:
setup.env fileでNUM_WAREHOUSEを576に変更して、完全に（100%）キャッシュに保存されたモードをテストします。詳細については、パフォーマンス評価のシナリオをご覧ください。
TPC-C データをデータベースに読み込む
読み込みステップとは、パフォーマンス テストを実行する前にベンチマーク データベースに初期データを入力するプロセスを指します。
読み込みステップでは、TPC-C 仕様に従って、指定された数の倉庫、顧客、その他のエンティティがデータベースに入力されます。負荷ステップの目的は、パフォーマンス テスト用の現実的なワークロードを作成し、テスト結果が異なるシステム間で比較できるようにすることです。
読み込みステップが完了すると、データベースは定義された一連の初期データと整合性のある状態になり、TPC-C ベンチマーク テストで使用できるようになります。
TPC-C データベースを読み込む手順は次のとおりです。
次のコマンドを使用して、ベンチマークのホーム ディレクトリに切り替えます。
cd hammerdb/HammerDB-4.6次のコンテンツをコピーして
build-tpcc.shに貼り付けます。#!/bin/bash -x source ./setup.env # create role tpcc with superuser login as 'postgres' and password as 'AlloyDB#123'; # ----------------------------------------------------- ./hammerdbcli << EOF # CONFIGURE PARAMETERS FOR TPCC BENCHMARK # -------------------------------------- dbset db pg dbset bm tpc-c # CONFIGURE POSTGRES HOST AND PORT # -------------------------------------- diset connection pg_host $PGHOST diset connection pg_port $PGPORT # CONFIGURE TPCC # -------------------------------------- diset tpcc pg_superuser postgres diset tpcc pg_superuserpass AlloyDB#123 diset tpcc pg_user tpcc diset tpcc pg_pass AlloyDB#123 diset tpcc pg_dbase tpcc # SET NUMBER OF WAREHOUSES AND USERS TO MANAGE EACH WAREHOUSE # THIS IMPORTANT METRIC ESTABLISHES THE DATABASE SCALE/SIZE # -------------------------------------- diset tpcc pg_count_ware $NUM_WAREHOUSE diset tpcc pg_num_vu 10 # LOG OUTPUT AND CONFIGURATION DETAILS # -------------------------------------- vuset logtotemp 1 print dict # CREATE AND POPULATE DATABASE SCHEMA # -------------------------------------- buildschema waittocomplete vudestroy quit EOF次の読み込みコマンドを実行し、コマンドが完了するまで待ちます。
chmod +x ./build-tpcc.sh mkdir results sudo nohup ./build-tpcc.sh > results/build-tpcc.out 2>&1負荷を検証します。前のスクリプトが完了したら、データベースの読み込みが正常に完了したことを確認することをおすすめします。データベースのサイズを確認するには、次のコマンドを実行します。
psql -h $PGHOST -p 5432 -U postgres postgres=> \l+ tpcc List of databases Name | Owner | Encoding | Collate | Ctype | Access privileges | Size | Tablespace | Description --------------+------------------+----------+---------+---------+---------------------------------------+---------+------------+-------------------------------------------- tpcc | tpcc | UTF8 | C.UTF-8 | C.UTF-8 | | --- GB | pg_default | | | | | | | 160.000 | | (1 row)
30% キャッシュに保存された TPC-C 構成（3,200 の倉庫を使用）では、tpcc データベースのサイズは約 300 GB になります。
100% キャッシュに保存された TPC-C 構成（576 個の倉庫を使用）では、tpcc データベースのサイズは約 55 GB になります。
TPC-C ベンチマークを実行する
これで、TPC-C パフォーマンス テストを実行する準備が整いました。TPC-C ベンチマークは、読み込みステップで入力されたデータベースを使用して実行されます。ベンチマークでは、注文入力、支払い処理、在庫管理など、一般的なビジネス環境をシミュレートする一連のトランザクションが生成されます。ワークロードは 1 分あたりのトランザクション数（TPM）で測定されます。これは、システムが 1 分で処理できる完全なビジネス トランザクションの数を表します。
実行ステップは、現実的な条件下でデータベース システムに負荷をかけ、さまざまなデータベース システム間で比較できるパフォーマンス測定の標準的な方法を提供するように設計されています。ベンダーとユーザーは、さまざまなデータベース システムとハードウェア構成のパフォーマンスを評価するために、TPC-C ベンチマークの結果を使用することがよくあります。
TPC-C ベンチマークを実行する手順は次のとおりです。
ベンチマークのホーム ディレクトリに切り替えます。
cd hammerdb/HammerDB-4.6次のコンテンツをコピーして
run-tpcc.shに貼り付けます。#!/bin/bash -x source ./setup.env ./hammerdbcli << EOF dbset db pg dbset bm tpc-c # CONFIGURE PG HOST and PORT # ------------------------- diset connection pg_host $PGHOST diset connection pg_port $PGPORT # CONFIGURE TPCC DB # ------------------------- diset tpcc pg_superuser postgres diset tpcc pg_superuserpass AlloyDB#123 diset tpcc pg_user postgres diset tpcc pg_pass AlloyDB#123 diset tpcc pg_dbase tpcc # BENCHMARKING PARAMETERS # ------------------------- diset tpcc pg_driver timed diset tpcc pg_rampup 10 diset tpcc pg_duration 60 diset tpcc pg_vacuum false diset tpcc pg_partition false diset tpcc pg_allwarehouse true diset tpcc pg_timeprofile true diset tpcc pg_connect_pool false diset tpcc pg_dritasnap false diset tpcc pg_count_ware $NUM_WAREHOUSE diset tpcc pg_num_vu 1 loadscript print dict vuset logtotemp 1 vuset vu $NUM_USERS vucreate vurun waittocomplete quit EOF次のコマンドを使用してスクリプトを実行します。
chmod +x run-tpcc.sh mkdir results sudo nohup ./run-tpcc.sh > results/run-tpcc.out 2>&1run-tpcc.shスクリプトが完了するまで待ちます。スクリプトの完了には約 1 時間 10 分ほどかかります。スクリプトが完了したら、結果を分析できます。
ベンチマーク結果を分析する
TPC-C ベンチマークでは、データベース システムのパフォーマンスを測定するために、1 分あたりの新規注文数（NOPM）と 1 分あたりのトランザクション数（TPM）のパフォーマンス指標が使用されます。
NOPM: システムが 1 分間に処理できる新規注文トランザクションの数を測定します。新規注文トランザクションは、TPC-C ベンチマークで最も重要なトランザクションの一つであり、顧客の新しい注文の作成が含まれます。
TPM: システムが 1 分で処理できる完了したビジネス トランザクションの合計数を測定します。トランザクションには、新規注文トランザクションのほか、支払い、配送、注文ステータスなど、TPC-C ベンチマークで定義されている他の種類のトランザクションも含まれます。
TPM は、現実的なワークロードを処理するシステムの能力を総合的に測定するため、TPC-C ベンチマークの主なパフォーマンス指標です。NOPM は、e コマースや小売システムなど、新規注文の処理に重点を置くシステムに有用な指標です。
16 vCPU マシンで 30% キャッシュに保存された TPC-C データベースの結果を表示する
このシナリオのパフォーマンス数を抽出するには、次のコマンドを使用します。
grep NOPM results/run-tpcc.out想定される出力は次のとおりです。
Vuser 1:TEST RESULT : System achieved 252970 NOPM from 582385 PostgreSQL TPM
16 個の vCPU マシン（NUM_WAREHOUSE=3200 と NUM_USERS=256 を使用）で 30% キャッシュに保存された TPC-C データベースでは、AlloyDB TPM の累積値が 582,385 で、tpm-C（1 分あたりの新規注文数）が 252,970 です。
16 個の vCPU マシンで 100% キャッシュに保存された TPC-C データベースの結果を表示する
16 個の vCPU マシン（NUM_WAREHOUSE=576 と NUM_USERS=256 を使用）で 100% キャッシュに保存された TPC-C データベースでは、累積 974,264 の AlloyDB TPM から 428,316 tpm-C（1 分あたりの新規注文数）が観測されます。
このシナリオのパフォーマンス数を抽出するには、次のコマンドを使用します。
grep NOPM results/tpcc-run.out想定される出力は次のとおりです。
Vuser 1:TEST RESULT : System achieved 428316 NOPM from 974264 PostgreSQL TPM
16 vCPU マシンでのパフォーマンス結果の概要
次の表に、16 vCPU マシンのベンチマーク パフォーマンスの結果を示します。
| TPC-C シナリオ | NUM_WAREHOUSE | NUM_USERS | NOPM | 累積 TPM |
|---|---|---|---|---|
| 30% キャッシュに保存 | 3200 | 256 | 252,970 | 582,385 |
| 100% キャッシュに保存 | 576 | 256 | 428,316 | 974,264 |
データベースのパフォーマンス指標をモニタリングする
データベース システムの動作を詳しく把握するには、AlloyDB モニタリング ツールを使用して、CPU 使用率、メモリ使用量、1 秒あたりのトランザクション数などの重要なシステム指標をモニタリングします。詳細については、インスタンスのパフォーマンスをモニタリングするをご覧ください。
たとえば、このベンチマークを実行した後、Google Cloud コンソールの AlloyDB の [概要] ページで、100% キャッシュに保存された TPC-C 実行の平均 CPU 使用率がほぼ 90% であることを確認できます。
64 vCPU の AlloyDB インスタンスで TPC-C ベンチマークを実行する
64 vCPU の AlloyDB インスタンスで TPC-C ベンチマークを実行するには、TPC-C ベンチマークを実行すると同じ設定手順に沿って、異なるマシンタイプを使用します。
AlloyDB とクライアント マシンを設定する
マシンタイプとして
64 vCPU, 512GBを指定して、AlloyDB クラスタとインスタンスを作成します。マシンタイプとして
n2-standard-64を指定して、クライアント マシンをプロビジョニングします。
ベンチマークを実行する
複数のベンチマークを連続して実行する場合は、ベンチマークのクリーンアップを行います。
クライアント マシンをセットアップします。次の値を置き換えます。
PGHOSTを、新しい 64 vCPU AlloyDB インスタンスのプライベート IP に設定します。- 30% キャッシュに保存された TPC-C シナリオの場合は、
NUM_WAREHOUSE=12800とNUM_USERS=1024を設定します。 - 100% キャッシュに保存された TPC-C シナリオの場合は、
NUM_WAREHOUSE=2304とNUM_USERS=1024を設定します。
TPC-C データベースを設定して読み込む。読み込みを高速化するには、
build-tpcc.shのpg_num_vuの値を 64 に変更します（diset tpcc pg_num_vu 64）。
ベンチマーク結果を分析する
次の表に、64 vCPU マシンでのベンチマーク パフォーマンスの結果を示します。
| ベンチマーク モード | NUM_WAREHOUSE | NUM_USERS | NOPM | 累積 TPM |
|---|---|---|---|---|
| 30% キャッシュに保存 | 12800 | 1024 | 589,598 | 1,371,160 |
| 100% キャッシュに保存 | 2304 | 1024 | 716,138 | 1,665,438 |
pgbench TPC-B ベンチマークを実行する
TPC-B（Transaction Processing Performance Council Benchmark B）は、PostgreSQL のベンチマーク ツールである pgbench で利用可能なベンチマーク モードの 1 つです。TPC-B は、複数の窓口係が顧客口座でトランザクションを実行する銀行のシナリオをシミュレートします。ワークロードは、次のタイプのトランザクションで構成されます。
- 預金
- 出金
- 残高照会
ベンチマークは、これらのトランザクションの組み合わせをシミュレートし、システムが処理できる 1 秒あたりのトランザクション数を測定して、データベース システムのパフォーマンスを測定します。
pgbench の TPC-B モードは、合成データベースを生成し、TPC-B ワークロードに似たトランザクションの組み合わせをシミュレートしますが、TPC 組織によって正式に認定されていません。したがって、pgbench の TPC-B モードは TPC-B のパフォーマンスを近似的に把握するのに役立ちますが、TPC-B 標準に準拠していると主張するために使用しないでください。
パフォーマンスを測定するシナリオ
このセクションでは、次のクリティカル モードで TPC-B のパフォーマンスを測定する方法について説明します。これらのモードで異なるパラメータは、SCALE_FACTOR パラメータの値のみです。
部分的にキャッシュに保存されたデータベースのシナリオ
このシナリオでは、--scale= 50000 を使用して大規模なデータベース（サイズ約 650 GB）を設定して初期化します。メモリに収まらず、大量のディスク I/O を引き起こす大規模なデータベースは、多くの本番環境ワークロードをリアルに表しています。
大量のディスク I/O が発生する大規模なデータベースでは、データベース設計とクエリの最適化の重要性が強調されます。大規模なデータベースでは、ディスク I/O に関連するパフォーマンスの問題（ディスク アクセスの遅延や効率の悪いクエリなど）が発生することもあります。これは、小規模なデータベースや完全にメモリに常駐するデータベースでは発生しない可能性があります。
キャッシュに完全に保存されたデータベースのシナリオ
このシナリオでは、--scale=4000 を使用してサイズが約 60 GB のデータベースを設定して初期化し、バッファプールに配置します。メモリに常駐するデータベースのベンチマークは、制御された環境でデータベース システムの最大パフォーマンスを評価できるため重要です。
メモリ内データベースでは、すべてのデータが PostgreSQL バッファプールに保存されるため、ディスクからデータにアクセスするときに発生する可能性のある I/O ボトルネックがなくなります。このモードでは、ディスク I/O に依存するデータベースをベンチマークするときには明らかでない、I/O に関連しないパフォーマンス ボトルネック（CPU 使用量やロックの問題など）を特定できます。
データベース サーバーとクライアント マシンを設定する
pgbench TPC-B ベンチマークを実行するインフラストラクチャを設定するには、次の操作を行います。
マシンタイプとして
16 vCPU, 128GBを指定して、AlloyDB クラスタとインスタンスを作成します。マシンタイプとして
E2-standard-16 (minimum)を指定して、クライアント マシンをプロビジョニングします。
pgbench TPC-B ベンチマークを実行する
次の Google Cloud CLI コマンドを使用して、クライアント マシンに接続します。
gcloud compute ssh --zone "PRIMARY_ZONE" "CLIENT_MACHINE_NAME" --project "GOOGLE_PROJECT"pgbench-setup.envファイルを作成します。$ cat << EOF > pgbench-setup.env # Private IP of the AlloyDB primary instance export PGHOST=<private_ip> # Set PGUSER to postgres as a default user. export PGUSER=postgres # Password set for PGUSER export PGPASSWORD=<your pg password> # In pgbench, the scale factor represents the size of the test database. # and is defined as the number of 1 MB-sized data pages to be generated per client. export SCALE_FACTOR=<scale_factor> # Number of clients to drive the benchmark in throughput mode export NUM_CLIENTS=<num_clients> EOF生成された
setup.envファイルを編集し、次のパラメータ値を環境の設定に適した値に置き換えます。- PRIVATE_IP: AlloyDB インスタンスのプライベート IP。
次の表を参照して、
<scale_factor>値と<num_clients>値を選択します。これらの値は、マシンタイプとデータベースのサイズ（完全にキャッシュに保存されているか、部分的にキャッシュに保存されているか）に合わせてスケーリングする必要があります。このガイドの例では、n2-highmem-16マシンタイプに対応するSCALE_FACTOR値とNUM_CLIENT値を使用します。完全にキャッシュに保存されている 部分的にキャッシュに保存 マシンタイプ SCALE_FACTOR NUM_CLIENTS SCALE_FACTOR NUM_CLIENTS n2-highmem-2 500 48 6250 32 n2-highmem-4 1000 96 12,500 個 64 n2-highmem-8 2000 192 25000 128 n2-highmem-16 4000 384 50000 256 n2-highmem-32 8000 768 100000 512 n2-highmem-64 16,000 1536 200000 1024 pgbenchデータベースを作成するsource ./pgbench-setup.env psql -h $PGHOST -p 5432 postgres=> create database pgbench; CREATE DATABASE次のコマンドを実行して、pgbench データベースを初期化して読み込みます。このステップでは、ベンチマーク データセットが作成され、現実的なデータが入力されます。これにより、pgbench データベースで TPC-B ワークロードを正確にシミュレートできます。
source ./pgbench-setup.env sudo nohup pgbench -i --host=$PGHOST --scale=$SCALE_FACTOR pgbench > /tmp/pgbench-tpcb-partially-cached-db-init.out 2>&1推定読み込み時間:
- 部分的にキャッシュに保存されたデータベースの読み込みには約 6 時間かかります。
- キャッシュに完全に保存されたデータベースの読み込みには約 45 分かかります。
省略可:
/tmp/pgbench-tpcb-partially-cached-db-init.outファイルの内容が次のようになっていることを確認して、負荷の精度チェックを実行します。generating data (client-side)... 100000 of 400000000 tuples (0%) done (elapsed 0.02 s, remaining 99.82 s) .. .. .. .. .. .. 399800000 of 400000000 tuples (99%) done (elapsed 534.60 s, remaining 0.27 s) 399900000 of 400000000 tuples (99%) done (elapsed 534.72 s, remaining 0.13 s) 400000000 of 400000000 tuples (100%) done (elapsed 534.85 s, remaining 0.00 s) vacuuming... creating primary keys... done in 1481.92 s (drop tables 0.01 s, create tables 0.04 s, client-side generate 540.93 s, vacuum 615.11 s, primary keys 325.84 s).省略可: 負荷の精度をさらに検証するには、すべての pgbench テーブルのサイズを測定する次の PostgreSQL コマンドを実行します。
pgbench データベースに接続します。
source ./pgbench-setup.env psql -h $PGHOST -p 5432 -U postgres -d pgbench次の SQL コマンドを実行します。
pgbench=> SELECT nspname AS schema_name, relname AS table_name, pg_size_pretty(pg_total_relation_size(C.oid)) AS size FROM pg_class C LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace) WHERE nspname NOT LIKE 'pg_%' AND nspname != 'information_schema' ORDER BY pg_total_relation_size(C.oid) DESC;前のコマンドの出力を、部分的にキャッシュに保存されたデータベース実行（
SCALE_FACTOR=50000）で取得した出力と比較します。schema_name | table_name | size -------------+-------------------------------------------+--------- public | pgbench_accounts | 731 GB public | pgbench_accounts_pkey | 105 GB public | pgbench_tellers | 32 MB public | pgbench_tellers_pkey | 11 MB public | pgbench_branches | 2952 kB public | pgbench_branches_pkey | 1112 kB .. .. .. public | pgbench_history | 0 bytes .. .. .. (29 rows)
次のコマンドを実行して、入金、振込、支払いを含む一連のトランザクションを実行し、財務会計システムのワークロードをシミュレートします。これにより、負荷の高いワークロードでのデータベースのパフォーマンスを測定できます。
source ./pgbench-setup.env mkdir -p ~/results/alloydb/pgbench sudo nohup pgbench --host=$PGHOST --builtin=tpcb-like --time=3900 --jobs=$NUM_CLIENTS --client=$NUM_CLIENTS --scale=$SCALE_FACTOR --protocol=prepared --progress=1 pgbench > ~/results/alloydb/pgbench/pgbench.run.out 2>&1
ベンチマーク結果を分析する
~/results/alloydb/pgbench/pgbench.run.out ファイルで、前のコマンドの出力を確認します。TPS の数値は、完全にキャッシュに保存されたデータベースと部分的にキャッシュに保存されたデータベースのシナリオで示されている数値に近い値になります。
データベースが完全にキャッシュに保存されている場合の結果
pgbench TPC-B ベンチマークを実行するの最後のコマンドの出力は、次のようになります。ここで、--scale=4000 は次のとおりです。
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 4000
query mode: prepared
number of clients: 384
number of threads: 384
duration: 3900 s
number of transactions actually processed: 84819501
latency average = 17.654 ms
latency stddev = 6.963 ms
tps = 21747.831164 (including connections establishing)
tps = 21750.579718 (excluding connections establishing)
データベース システムの動作を詳しく把握するには、Google Cloud コンソールを使用して、CPU 使用率、メモリ使用量、1 秒あたりのトランザクション数などのシステム指標をモニタリングします。詳細については、インスタンスをモニタリングするをご覧ください。
部分的にキャッシュに保存されたデータベースの結果
pgbench TPC-B ベンチマークを実行するの最後のコマンドの出力は、次のようになります。ここで、--scale=50000 は次のとおりです。
pgbench: warning: scale option ignored, using count from pgbench_branches table (50000)
starting vacuum...end.
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 50000
query mode: prepared
number of clients: 384
number of threads: 384
duration: 3900 s
number of transactions actually processed: 68073405
latency average = 21.992 ms
latency stddev = 29.272 ms
tps = 17453.913041 (including connections establishing)
tps = 17460.373303 (excluding connections establishing)
pgbench TPC-B ベンチマークのパフォーマンス結果の概要
次の表に、pgbench TPC-B ベンチマークのパフォーマンス結果を示します。
| TPC-B シナリオ | SCALE_FACTOR | TPS | CPU 使用率（%） |
|---|---|---|---|
| 一部キャッシュに保存 | 50000 | 17,460 | 96% |
| キャッシュに完全に保存されている | 4000 | 21,750 | 94% |
インデックス挿入のみのベンチマークを実行する
インデックス挿入のみのベンチマークは、書き込み負荷の高い同時実行シナリオです。このセクションでは、ほとんどの OLTP アプリケーションで AlloyDB のパフォーマンス上のメリットを示すために、このシナリオをカスタマイズしています。このベンチマークを実行するには、pgbench_history テーブルに複数のインデックスを作成し、複数のクライアント接続から pgbench_history テーブルに対して INSERT オペレーションを繰り返し実行します。
インデックスのみ挿入ベンチマークは、データベース テーブルへのデータ挿入のパフォーマンスを測定します。特に、書き込みオペレーションに対するインデックスの影響に焦点を当てています。このベンチマークでは、インデックスありとインデックスなしの両方で、テーブルに新しい行を追加する速度を把握し、挿入時のインデックスのメンテナンスによって発生する可能性のある速度低下をハイライトします。
AlloyDB は PostgreSQL の書き込みパフォーマンスを向上させ、OLTP ワークロードも改善します。書き込み負荷の高い OLTP シナリオのパフォーマンスを向上させるため、AlloyDB では、読み取りを支援する階層化キャッシュレイヤや、書き込み用の分散かつ高度にスケーラブルなストレージ エンジン テクノロジーなど、アーキテクチャの革新が導入されています。
AlloyDB とクライアント マシンを設定する
インデックスのみ挿入ベンチマークを実行するインフラストラクチャを設定する手順は次のとおりです。
マシンタイプとして
16 vCPU and 128 GB RAMを指定して、AlloyDB クラスタとインスタンスを作成します。マシンタイプとして
E2-standard-16 (minimum)を指定して、クライアント マシンをプロビジョニングします。
インデックス挿入のみのベンチマークを実行する
次のコマンド例を使用して、クライアント マシンに接続します。
gcloud compute ssh --zone "<primary zone>" "<client machine name>" --project "<google-project>"次のコマンドを実行して環境を設定します。
export PGHOST=<private_ip>次の例を使用して
pgbenchデータベースを作成します。データベースがすでに存在する場合は、データベースを削除して再作成します。psql -h $PGHOST -p 5432 -U postgres -c "DROP DATABASE IF EXISTS pgbench" psql -h $PGHOST -p 5432 -U postgres -c "CREATE DATABASE pgbench"pgbench データベースを初期化して読み込み、ベンチマーク データセットが作成され、現実的なデータが入力されていることを確認します。ハイライト表示されたパラメータを編集し、次のコマンドを実行します。
sudo nohup pgbench -i --host=$PGHOST --user=postgres --scale=25000 pgbench > /tmp/pgbench-index-insert-only-init.out 2>&1 ... postgres=> create database pgbench; CREATE DATABASE pgbench上記のコマンドの出力が次のようになることを確認します。
dropping old tables... creating tables... generating data (client-side)... 100000 of 2500000000 tuples (0%) done (elapsed 0.03 s, remaining 636.43 s) 200000 of 2500000000 tuples (0%) done (elapsed 0.05 s, remaining 649.12 s) .. .. .. .. .. .. 2499900000 of 2500000000 tuples (99%) done (elapsed 3425.42 s, remaining 0.14 s) 2500000000 of 2500000000 tuples (100%) done (elapsed 3425.57 s, remaining 0.00 s) vacuuming... creating primary keys... done in 12851.19 s (drop tables 998.62 s, create tables 0.02 s, client-side generate 3460.33 s, vacuum 5299.93 s, primary keys 3092.29 s).次のコマンドを使用して
index-init.sqlスクリプトを作成します。cat > index-init.sql << EOF CREATE INDEX tid ON pgbench_history(tid); CREATE INDEX bid ON pgbench_history(bid); CREATE INDEX aid ON pgbench_history(aid); CREATE INDEX delta ON pgbench_history(delta); CREATE INDEX mtime ON pgbench_history(mtime); EOFindex-init.sqlスクリプトを実行します。psql -h $PGHOST -U postgres -d pgbench -f ./index-init.sql Password for user postgres: CREATE INDEX省略可: データベース スキーマと初期読み込みを検証します。
psql -h $PGHOST -U postgres -d pgbench pgbench=> \dt List of relations Schema | Name | Type | Owner --------+------------------+-------+---------- public | pgbench_accounts | table | postgres public | pgbench_branches | table | postgres public | pgbench_history | table | postgres public | pgbench_tellers | table | postgres (4 rows) pgbench=> \di List of relations Schema | Name | Type | Owner | Table --------+-----------------------+-------+----------+------------------ public | aid | index | postgres | pgbench_history public | bid | index | postgres | pgbench_history public | delta | index | postgres | pgbench_history public | mtime | index | postgres | pgbench_history public | pgbench_accounts_pkey | index | postgres | pgbench_accounts public | pgbench_branches_pkey | index | postgres | pgbench_branches public | pgbench_tellers_pkey | index | postgres | pgbench_tellers public | tid | index | postgres | pgbench_history (8 rows)読み込み後のデータベースのサイズは約 365 GB になります。
pgbench=> \l+ pgbench List of databases Name | Owner | Encoding | Collate | Ctype | Access privileges | Size | Tablespace | Description --------------+------------------+----------+---------+---------+---------------------------------------+--------+------------+-------------------------------------------- ... pgbench | postgres | UTF8 | C.UTF-8 | C.UTF-8 | | 365 GB | pg_default | ...次のコマンドを使用して
index-inserts-only.sqlスクリプトを作成します。cat > index-inserts-only.sql << EOF \set aid random(1, 1000000000) \set bid random(1, 1000000000) \set tid random(1, 1000000000) \set delta random(-500000000, 500000000) BEGIN; INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP); END; EOF次のコマンドを使用して、pgbench ベンチマークを実行します。
sudo nohup pgbench --host=$PGHOST --user=postgres --time=3900 --client=256 --jobs=256 --scale=25000 --progress=1 --file=./index-inserts-only.sql pgbench > /tmp/pgbench-index-insert-only-run.out 2>&1
ベンチマーク結果を分析する
/tmp/pgbench-index-insert-only-run.out ファイルで、前のコマンドの出力を確認します。このベンチマーク テストでは、次の出力例に示すように、1 秒あたり約 52, 000 件のトランザクションと約 88% の CPU 使用率が表示されます。
scaling factor: 25000
query mode: simple
number of clients: 256
number of threads: 256
duration: 3900 s
number of transactions actually processed: 201785196
latency average = 4.947 ms
latency stddev = 3.488 ms
tps = 51738.604613 (including connections establishing)
tps = 51742.459757 (excluding connections establishing)
64 vCPU インスタンスで Select Only ベンチマークを実行する
pgbench は、指定されたデータベースに対して複数のクライアント接続から SELECT クエリを繰り返し実行する、組み込みの選択専用シナリオをサポートしています。このベンチマークは、INSERT、UPDATE、DELETE などのデータ変更オペレーションのオーバーヘッドを発生させることなく、データベースの読み取りパフォーマンスを測定するために使用されます。これらの SELECT クエリはポイント検索クエリです。インデックス構造から直接 1 行のデータにのみアクセスするため、最も高速で効率的なタイプの SELECT クエリです。
選択のみのベンチマークを実行すると、次のことができます。
最大スループットの達成: インデックスでのポイント検索はデータベース システムで最も効率的なクエリ形式であるため、AlloyDB が達成できる最大スループットを測定できます。
スケーラビリティ: 選択したベンチマークのみを使用して、AlloyDB のスケーラビリティを 2 つの vCPU から AlloyDB が提供する最大の vCPU 構成までテストできます。
AlloyDB とクライアント マシンを設定する
64 vCPU マシンタイプに AlloyDB とクライアント マシンを設定します。
Select Only ベンチマークを実行する
次のコマンド例を使用して、クライアント マシンに接続します。
gcloud compute ssh --zone "PRIMARY_ZONE" "CLIENT_MACHINE_NAME" --project "GOOGLE_PROJECT"次のコマンドを使用して環境を設定します。
export PGHOST=<private_ip>次の例を使用して、pgbench データベースを作成します。
psql -h $PGHOST -p 5432 -U postgres postgres=> create database pgbench; CREATE DATABASEpgbench データベースを初期化します。次のコマンドは、約 220 GB の現実的なデータで pgbench データベースを初期化します。
--scale=15000は、完全にキャッシュに保存された「選択のみ」ベンチマークに使用します。次のコマンドを実行します。
sudo nohup pgbench -i --host=$PGHOST --user=postgres --scale=15000 pgbench > /tmp/pgbench-select-only-init.out 2>&1上記のコマンドの出力が次のようになることを確認します。
cat /tmp/pgbench-select-only-init.out nohup: ignoring input dropping old tables... creating tables... generating data (client-side)... 100000 of 1500000000 tuples (0%) done (elapsed 0.01 s, remaining 161.60 s) 200000 of 1500000000 tuples (0%) done (elapsed 0.03 s, remaining 224.35 s) 300000 of 1500000000 tuples (0%) done (elapsed 0.09 s, remaining 448.97 s) .. .. .. .. .. .. 1499900000 of 1500000000 tuples (99%) done (elapsed 1251.03 s, remaining 0.08 s) 1500000000 of 1500000000 tuples (100%) done (elapsed 1251.10 s, remaining 0.00 s) vacuuming... creating primary keys... done in 2204.62 s (drop tables 2.29 s, create tables 0.01 s, client-side generate 1271.82 s, vacuum 427.83 s, primary keys 502.66 s).pgbench を実行します。この最後のベンチマーク ステップの完了には 1 時間以上かかります。
sudo nohup pgbench --host=$PGHOST --user=postgres --builtin=select-only --time=3900 --jobs=256 --client=256 --scale=15000 --protocol=simple --progress=1 pgbench > /tmp/pgbench-select-only-run.out 2>&1ベンチマークが完了したら、
/tmp/pgbench-select-only-run.outファイルで最終結果を確認します。
ベンチマーク結果を分析する
このベンチマーク テストでは、次の出力例に示すように、1 秒あたり約 467, 000 件のトランザクションと約 95% の CPU 使用率が観測されます。
cat /tmp/pgbench-select-only-run.out
transaction type: <builtin: select only>
scaling factor: 15000
query mode: simple
number of clients: 256
number of threads: 256
duration: 3900 s
number of transactions actually processed: 1823506174
latency average = 0.547 ms
latency stddev = 0.267 ms
tps = 467563.144333 (including connections establishing)
tps = 467583.398400 (excluding connections establishing)
AlloyDB ベンチマーク結果の概要
次の表に、このドキュメントで実施したテストに基づく AlloyDB ベンチマークの結果を示します。
HammerDB TPC-C のパフォーマンスの概要
| AlloyDB マシンタイプ | TPC-C ワークロード シナリオ | NUM_WAREHOUSE | NUM_USERS | 1 分あたりの新規注文数（NOPM） | 累積 TPM | TPS に変換 |
|---|---|---|---|---|---|---|
| 16vCPU | 30% キャッシュに保存 | 3200 | 256 | 252,970 | 582,385 | 9,706 |
| 16vCPU | 100% キャッシュに保存 | 576 | 256 | 428,316 | 974,264 | 16,238 |
| 64vCPU | 30% キャッシュに保存 | 12800 | 1024 | 589,598 | 1,371,160 | 22,853 |
| 64vCPU | 100% キャッシュに保存 | 2304 | 1024 | 716,138 | 1,665,438 | 27,757 |
pgbench のパフォーマンスの概要
| AlloyDB マシンタイプ | pgbench ワークロード シナリオ | スケール ファクタ | TPS | CPU % |
|---|---|---|---|---|
| 16vCPU | TPC-B に似た、完全にキャッシュに保存されたワークロード | 4000 | 20,359 | 96% |
| 16vCPU | TPC-B に似た、部分的にキャッシュに保存されたデータ | 50000 | 14,060 | 94% |
| 16vCPU | インデックスの挿入のみ | 25000 | 51,742 | 88% |
| 64vCPU | 最大スループット（選択のみ） | 15000 | 467,583 | 95% |
Cloud SQL for PostgreSQL で OLTP ベンチマークを実行する
16 vCPU マシンタイプで Cloud SQL for PostgreSQL の PostgreSQL で同等の OLTP パフォーマンスをテストして、比較分析を行うことができます。このセクションでは、このガイドで OLTP パフォーマンスのベンチマークに使用されている AlloyDB 設定と同等の Cloud SQL for PostgreSQL（または任意のインフラストラクチャにデプロイされた PostgreSQL サーバー）を設定する方法について説明します。このシナリオでは、16vCPU SKU の選択、高可用性（HA）の有効化、ストレージの事前構成が含まれます。
始める前に
- Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
- Install the Google Cloud CLI.
-
To initialize the gcloud CLI, run the following command:
gcloud init -
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
- Install the Google Cloud CLI.
-
To initialize the gcloud CLI, run the following command:
gcloud init -
ユーザー アカウントに Cloud SQL 管理者のロールと Compute 閲覧者のロールがあることを確認します。
ロールと権限について詳細を確認します。
Cloud SQL for PostgreSQL インスタンスをプロビジョニングする
PostgreSQL インスタンスを作成します。次の値を置き換えます。
- データベースのバージョン: PostgreSQL 14
- 最初に使用する構成を選択します。[本番環境]
- リージョンとゾーンの可用性の選択: リージョンとして [
us-central1] を選択します。 - ゾーンの可用性: 複数のゾーン（高可用性）
- プライマリ ゾーン:
us-central1-c - セカンダリ ゾーン:
us-central-1-f
- プライマリ ゾーン:
- マシンタイプ: ハイメモリ 16 vCPU、104 GB マシン。これは、このドキュメントの AlloyDB ベンチマーク セクションで作成した AlloyDB インスタンスに最も近い、Cloud SQL for PostgreSQL が提供するマシンです。
- ストレージ容量: カスタム、1, 500 GB
- ストレージの自動増量を有効にする
- 暗号化: Google-owned and Google-managed encryption key
- 接続: プライベート IP
- ネットワーク:
default - パブリック IP: 有効
- ネットワーク:
[インスタンスを作成] をクリックします。
PostgreSQL インスタンスの作成後、プライベート IP アドレスをメモします。IP を
PGHOSTとして使用して、ベンチマークとの接続を確立します。
クライアント マシンをプロビジョニングする
Cloud SQL for PostgreSQL インスタンスをプロビジョニングします。選択した OLTP ベンチマークを実行するには、Cloud SQL のプライマリ Cloud SQL for PostgreSQL インスタンスと同じゾーンに、十分な CPU パワーを備えたクライアント マシンが必要です。
省略可: 次の条件を満たしている場合、前の手順の代わりに、AlloyDB ベンチマークに設定したクライアント マシンを使用できます。
- クライアント マシンが、新しい PostgreSQL（Cloud SQL for PostgreSQL）プライマリ インスタンスと同じゾーンにある。
- クライアント マシンが CPU、RAM、ディスクサイズの最小要件を満たしている。
このベンチマーク ガイドでは、プライマリ インスタンスと同じゾーンに配置されているクライアント マシンを再利用し、サーバーを最大容量に到達させるのに十分な大きさのクライアント マシンを再利用しました。
新しいクライアント マシンを作成した場合は、ベンチマーク ドライバ マシンをセットアップします。それ以外の場合は、実行するベンチマークに関するこのガイドの手順に沿って操作します。