パフォーマンス検証とベンチマーク結果
変更を提案
PDF
このパフォーマンス検証の目的は、何らかのマークを設定することではありません。むしろ、このドキュメントで概説されているデプロイメント手順とベスト プラクティスに従えば、パブリック クラウドでの Oracle データベース デプロイメントで同様のパフォーマンス メトリックが期待できます。
Swingbench Sales Order Entry (SOE) モジュールを使用して OLTP タイプのワークロードをシミュレートし、NFS プロトコル上の FSx ストレージボリュームを持つ M5 EC2 インスタンスにデプロイされた Oracle データベースにワークロードを適用しました。デフォルトの Swingbench SOE I/O プロファイルは、80/20 の読み取り/書き込み分割に近く、これは実際の OLTP Oracle ワークロード プロファイルに近いです。
販売注文の入力、閲覧、在庫照会などを実行するクライアント側の同時ユーザー数が増加すると、ワークロードが増加します。テストされた同時ユーザー数は 8、16、32、64、128 人でした。 Swingbench が使用するアルゴリズムは、サーバー側で負荷がかかり、妥当なトランザクション ボリュームをプッシュして Oracle サーバーの制限をテストします。同時ユーザー数が 128 人の場合、EC2 インスタンスの CPU 使用率が約 80 ～ 90% に達することがわかりました。
次のセクションでは、セットアップとテスト結果の詳細について説明します。
テスト環境のセットアップ
コンピューティング
8vCPU、32G RAM、10Gps のネットワーク帯域幅を備えた EC2 M5 インスタンスをデプロイしました。
FSxストレージ
次のように、3 つのデータベース ボリュームを作成し、EC2 インスタンスに NFS を使用してボリュームをマウントしました。
-
/u01 - Oracleバイナリ
-
/u02 - Oracleデータファイル、制御ファイル
-
/u03 - Oracle ログファイル、制御ファイル
冗長性のために重要な制御ファイルのコピーを 2 つ保存しました。
FSx ファイル システムは、80,000 IOPS 容量と 2GiBps I/O スループットで構成されています。
Oracle構成
Oracle バージョン 19c と RU パッチ 19.8 をインストールしました。サーバー上で dNFS が有効になりました。
データベースは、3 つの PDB を含むコンテナ化されたデータベースとしてデプロイされました。パフォーマンス テストには 1 つの PDB インスタンスを使用しました。次の図は、NFS マウント ポイント上の Oracle ストレージのサイズを示しています。
スイングベンチ構成
8vCPU と 32G RAM を搭載した Windows ホストに Swingbench 2.6 (最新バージョン) を導入しました。ベンチマークには SOE plsql テスト モジュール バージョン 2 を使用しました。デフォルトの負荷プロファイルは、実際の OLTP トランザクション ワークロードをシミュレートするために 80/20 の読み取り/書き込み比率を提供します。
使用したスキーマ スケール係数は 50 で、初期データ ロード サイズは 160 G で、一時スペースの割り当ては 30 G でした。このスケール ファクターでは、SOE スキーマは、オンライン注文処理のシミュレーション用に 1,000 の倉庫と 5,000 万の顧客を提供しました。
次のスクリーン ショットは、Swingbench Windows UI からのワークロード プロファイルと一般的なトランザクション実行メトリックを示しています。
このグラフが示すように、トランザクション レベルはテスト実行全体を通じて同じレベルで維持されました。
テスト結果の分析
各テスト実行の Swingbench 結果をキャプチャし、パフォーマンス分析用の対応する Oracle AWR レポートを取得しました。
エンドユーザー側では、トランザクション量やユーザー応答時間などの主要な指標に注目しました。両方の指標は、システムに同時ログインしているユーザーの数を考慮して、ユーザーが販売注文入力システムから実行できるトランザクションの数と、ユーザーが注文を入力した後にトランザクションを完了して応答を受け取るまでの速さを示します。
Oracle サーバー側では、Oracle AWR レポートを解析して、ユーザー トランザクションの速度を低下させた可能性のある上位の待機イベントを特定しました。 Oracleの待機イベント上位10件は、Swingbenchのシミュレートされたトランザクションテスト実行中に、Oracleサーバーが主にI/Oバウンドであり、データベース時間の50%～60%がI/Oバウンドに費やされていることを示しています。 db file sequential read 。 `log file sync`トランザクションのコミットにより、Oracle ログ記録プロセスによってログ I/O がバッファ キャッシュからディスク上のログ ファイルにフラッシュされるため、データベース時間の割合レベルでは小さな要因ではありますが、これも一因となります。
トランザクション実行中の同時ユーザー数に対するユーザー トランザクション量、ユーザー応答時間、および Oracle のトップ待機イベントをグラフ化しました。結果は以下の通りです。
これらの結果は、同時ユーザー数の増加に伴ってユーザー トランザクション量を着実に増やしながら、一貫して低い I/O レイテンシとユーザー応答時間を維持できることを示しています。これは、Oracle アプリケーションに適切なパフォーマンスです。
同時ユーザー数が 128 に達した時点で、I/O レイテンシとユーザー応答時間が若干増加し始めました。これは、次の図に示すように、EC2 インスタンスがサーバーの全容量に近づいているために予想されたことです。
同様に、次の図は、その時点でのユーザー トランザクション ボリュームを満たしているときの対応する FSx IOPS とスループットを示しています。
Oracle サーバーの EC2 インスタンスが制限要因となったため、IOPS またはスループットのいずれにおいても、プロビジョニングされた FSx ストレージ容量に到達できませんでした。したがって、次のセクションで示すように、ユーザーアプリケーションレベルのトランザクション量に基づいてコンピューティングとストレージのサイズを適切に決定する必要があります。"Oracle データベースの導入時に考慮すべき要素。"