なからなLife

geekに憧れと敬意を抱きながら、SE、ITコンサル、商品企画、事業企画、管理会計、総務・情シス、再び受託でDB屋さんと流浪する人のブログです。

HammerDB 4.0がリリースされていた - 複数インスタンスへの接続・負荷試験 その２

HammerDB

HammerDB 4.0がリリースされていた - リリースノートチェック - なからなLife
HammerDB 4.0がリリースされていた - 環境構築 - なからなLife
HammerDB 4.0がリリースされていた - 設定まわりの変化 - なからなLife
HammerDB 4.0がリリースされていた - ワークロードの実行 - なからなLife
HammerDB 4.0がリリースされていた - 複数インスタンスへの接続・負荷試験 その１ - なからなLife
の続きです。

HammerDB4.0のMySQL-OLTP（TPC-C）にバグがあった

前回のエントリの通り、GitHubにIssue上げたらソッコーで中の人が対処してくれて、v4.1には入ってきそうな勢いです。
どこをどう修正するかははっきりしていて範囲も狭いので、実際にソース直して試してみます。

Fix for Issue #216 Unkown prepared statement handler with connect pool by sm-shaw · Pull Request #217 · TPC-Council/HammerDB · GitHub


さっそく試験。

条件は前回記述したものと同です。

なお、分散負荷を有効にした場合、このような出力になります。

  • user1がモニタリングセッション。マスター（mysqlcpool.xmlではなくdictで指定した接続先）に接続して情報を取得し、結果を表示。
    • 「TEST RESULT」は1台分の情報。振り分け方にもよるが、DBクラスター全体のスループットを見るには、クラスターを構成する台数分だけ乗算する必要がある。（とドキュメントに書いてあるが、それでいいのか？
  • 「CLIENT SIDE TPM」
    • vuごと、各プロシージャの実行量を表示。
Vuser 1:Test complete, Taking end Transaction Count.
Vuser 1:4 Active Virtual Users configured
Vuser 1:TEST RESULT : System achieved 7674 NOPM from 23008 MySQL TPM
Vuser 5:VU5 processed neworder 13622 payment 13602 delivery 1331 stocklevel 1392 orderstatus 1341 transactions
Vuser 5:FINISHED SUCCESS
Vuser 4:VU4 processed neworder 13572 payment 13755 delivery 1315 stocklevel 1321 orderstatus 1329 transactions
Vuser 2:VU2 processed neworder 13734 payment 13631 delivery 1345 stocklevel 1377 orderstatus 1401 transactions
Vuser 4:FINISHED SUCCESS
Vuser 2:FINISHED SUCCESS
Vuser 3:VU3 processed neworder 13699 payment 13592 delivery 1348 stocklevel 1325 orderstatus 1364 transactions
Vuser 3:FINISHED SUCCESS
Vuser 1:CLIENT SIDE TPM : neworder 7803 payment 7797 delivery 762 stocklevel 773 orderstatus 776
Vuser 1:FINISHED SUCCESS
（1）MySQL ソース1：レプリカ1構成

(1-1)すべてソース側に振る構成（レプリカへの接続設定は入れつつ、リクエストを投げない）
(1-2)参照のみはすべてリードレプリカ、更新ありはソース側に振る構成
(1-3)参照のみはソースとレプリカの2台に、更新ありはソース側に振る構成
(1-4)更新も双方に（エラーになるはず）
を試します。

Aurora MySQL マルチマスター（2台）構成

(2-1)更新も参照も全台に
を試します。
それ以外は、上記で済んでるはずなので。



結果

(1-1)すべてソース側に振る構成（レプリカへの接続設定は入れつつ、リクエストを投げない）
想定通り、ソース側にのみリクエストが飛んできます。
レプリカ側には、設定したvu数のセッションが貼られますが、リクエストは来ません。


(1-2)参照のみはすべてリードレプリカ、更新ありはソース側に振る構成
参照系の負荷を発生させるストアドプロシージャOSTATとSLEVが、リードレプリカ側だけに飛んできていることが、General Logから確認できました。
もちろん、更新系の処理はソース側のみに飛んできていました。


(1-3)参照のみはソースとレプリカの2台に、更新ありはソース側に振る構成
参照系の負荷を発生させるストアドプロシージャOSTATとSLEVが、ソースとリードレプリカの両方に飛んできていることが、General Logから確認できました。
もちろん、更新系の処理はソース側のみに飛んできていました。


(1-4)更新も双方に（エラーになるはず）
リードレプリカにも更新リクエストを投げていますので、想定通り、

 Vuser 2:mysqlexec/db server: The MySQL server is running with the --read-only option so it cannot execute this statement

が大量に出力されます。

なお、「エラーで即終了＋リトライ」を繰り返すので、トータル処理回数はエラーがないときよりも大きな数字が報告されます。


(1-1)から(１-4)は、こんな感じです。
f:id:atsuizo:20210406134655p:plain
上2段：CloudWatch Logs Insightsで、ソースとレプリカに飛んできたリクエストのGeneral Logから、「OSTAT」「SLEV」ストアドプロシージャ（＝参照負荷）をCALLしているログを抽出した結果の件数推移
下1段：CloudWatch Metricsで、ソースとレプリカのCPU使用率、DB接続数の推移
４つの山になっているのが、順に試験（1-1）～（1-4）になっています。


(2-1)更新も参照も全台に
たしかに双方に更新参照両方のリクエストが届いていて、処理はされているのですが、だからこそ、デッドロック出まくりました。。。

ページレベルで競合するとデッドロックが検出されることは、Auroraのドキュメントにもはっきり書いてあるので、当然といえば当然。。。







まとめ
  • HammerDB4.0の対MySQL用OLTPワークロードのクラスター対応にはバグがあるので、4.1？が出るまではソースを直接書き換えで対応が必要
  • （修正版では）、コネクションプール設定で更新・参照ワークロードの向き先を設定可能。期待通りに動いた！
  • Auroraマルチマスターに対して、２台のマスターに負荷をかけることはできたが、デッドロック頻発で意味のある数字は取れないと考えて良さそう。


PostgreSQL用はバグがないのがわかっていたし、あと試してみたいのはOracle RAC/ActiveDataGuardかなあ。
直近では検証する時間がなさそうですので、HammerDB4.0についての記事はいったんここで一区切りとします。