HammerDBをCLIで使うなど（２）：MySQLにTPC-Cを実行してみる

基本的な流れ

どのDBに対して、どのワークロードをかける場合でも共通ですが、まずは「MySQLにTPC-C」を実行して、その流れを見ておきます。
GUIで一度経験しておくと、イメージがよりつかみやすいかもしれません。

1. DB種類選択
2. ベンチマーク種類選択
3. スキーマパラメータ調整
4. スキーマ構築
5. 負荷をかけるクライアントのパラメータ調整
6. 負荷実行

対象DBMS選択

dbset db {ora | mssqls | db2 | mysql | pg | redis}

ですので、このようにします。

hammerdb>dbset db mysql
Database set to MySQL

このコマンドの実行時点では、ドライバの設定状況まではチェックしていない模様。

実行するベンチマークの種類の選択

dbset bm {TPC-C | TPC-H}

選択したDBによって、使用できるベンチマークの選択肢も変わります。redisだとTPC-H使えないので、GUIだとグレーアウトされてますね。

今回は、以下のようになります。

hammerdb>dbset bm TPC-C
Benchmark set to TPC-C for MySQL

詳細パラメータの表示と設定

データベースとベンチマークを指定したあと、「print dict」を指定すると、指定可能な詳細パラメータが「Key SubKey Value」形式で出力されます。

hammerdb>print dict
Dictionary Settings for MySQL
connection {
 mysql_host = 127.0.0.1
 mysql_port = 3306
}
tpcc       {
 mysql_count_ware       = 1
 mysql_num_vu           = 1
 mysql_user             = root
 mysql_pass             = mysql
 mysql_dbase            = tpcc
 mysql_storage_engine   = innodb
 mysql_partition        = false
 mysql_total_iterations = 1000000
 mysql_raiseerror       = false
 mysql_keyandthink      = false
 mysql_driver           = test
 mysql_rampup           = 2
 mysql_duration         = 5
 mysql_allwarehouse     = false
 mysql_timeprofile      = false
}

ここで、「diset Key SubKey 設定する値」を使って、それぞれの項目を変更していきます。

パラメータの意味は以下のとおりです。

名称	説明	初期値
mysql_count_ware	シナリオに登場する「倉庫（warehouse）の数＝データのサイズ（≒スケールファクタ）。	1
mysql_num_vu	同時実行ユーザー数	1
mysql_user	テストに使用するユーザー。予め対象のMySQLに作成されている必要がある。	root
mysql_pass	テストに使用するユーザーのパスワード。	mysql
mysql_dbase	テストに使用するデータベース（スキーマ）名。	tpcc
mysql_storage_engine	テストに使用するテーブルのストレージエンジン。	innodb
mysql_partition	"ORDER_LINE”テーブルをパーティショニングテーブルにするスイッチ。ってことになっているけど、tureにしてもパーティショニングされなかった。。。	false
mysql_total_iterations	トランザクションの実行回数。	1000000
mysql_raiseerror	エラーが起きても続ける（false)か、exitする（true）かのスイッチ。	false
mysql_keyandthink	公式TPC-C要件により近づけるための「思考判断時間」のシミュレートを行うスイッチ。	false
mysql_driver	環境整整備、動作検証までは「test」を、実計測時は「timed」を指定する。	test
mysql_rampup	いわゆるテスト開始～計測開始までの暖気処理時間。	2
mysql_duration	複数ユーザーが時差を持ってアクセスするための遅延処理。	5
mysql_allwarehouse	シナリオに登場する倉庫（warehouse）に対し、ユーザーが利用する倉庫はデフォルトでは固定されるが、trueにするとランダムに倉庫を選択するようになる。	false
mysql_timeprofile	応答時間プロファイル（etprof）の生成スイッチ。trueにすると、10秒間隔での応答時間パーセンタイル、完了時の累積値がレポートされる。	false

今回、pg_host、pg_user、pg_userpass以外では、以下を変更して実行します。

hammerdb>diset tpcc mysql_driver timed
Clearing Script, reload script to activate new setting
Script cleared
Changed tpcc:mysql_driver from test to timed for MySQL

hammerdb>diset tpcc mysql_timeprofile false
Value false for tpcc:mysql_timeprofile is the same as existing value false, no change made

driverをtestにしておくと、大量のログが出力されます。
動作確認用に、mysql_total_iterationsを小さくしてtestで流して様子を見る、という使い方はあると思いますが、真面目に動かすときはtimedを使います。

なお、timedじゃないときにtimeprofileをtrueにするとエラーになるようです。

スキーマ作成

テストで流す前に必要なスキーマ作成、及び、テストデータの投入を実行します。

前述「mysql_user」で指定したMySQLユーザーは、接続先となるMySQLの中に予め作成しておいてください。
データベースの方は、なければ勝手に作ってくれますが、ユーザーは流石にそうはいきませんので。

mysql_num_vuで指定した数だけクライアントが立ち上がり、並列実行でテストデータを投入します。
（ mysql_count_ware > mysql_num_vu　にしないとエラーになります。）

hammerdb>buildschema
....
ALL VIRTUAL USERS COMPLETE

処理が完了しても、データ生成のために立ち上がったクライアントプロセスは起動したままになります。
次の処理の前に、スキーマ作成用のユーザーセッションが完了しているか確認するコマンドを投げて確認し、完了ステータスになっていたら、そのセッションは一度破棄しておきます。

hammerdb>vustatus
1 = FINISH SUCCESS

hammerdb>vudestroy
Destroying Virtual Users
Virtual Users Destroyed
vudestroy success

hammerdb>vustatus
No Virtual Users found

テストスクリプトのロード

テストを実行するにあたり、これまでの設定からワークロードを発生させるためのスクリプトをロードします。

hammerdb>loadscript
Script loaded, Type "print script" to view

読み込んだスクリプトは「print script」で表示できますが、ほんとうにtcl/tkスクリプトがダラダラ表示されるだけなので、ここでは割愛。

テスト実行用クライアント（Virtual User）の設定

さらに、ワークロードを実行するために接続する同時実行ユーザー数を確認・調整します。

hammerdb>print vuconf
Virtual Users = 1
User Delay(ms) = 500
Repeat Delay(ms) = 500
Iterations = 1
Show Output = 1
Log Output = 0
Unique Log Name = 0
No Log Buffer = 0
Log Timestamps = 0

パラメータの意味は「読んで字の如く」です。

「Virtual Users」は、スキーマ作成時のmysql_num_vuから導出され、mysql_num_vu=1ならば「1」、2以上ならば「mysql_num_vu+1」がデフォルト設定されます。

必要に応じて「vuset Key Value」で設定変更します。デフォルトで0になっている部分は、基本的に「1」にしておくと良いです。
（なぜかNo Log Bufferは「vuset nobuff 1」でも変更できなかったので無視します）

ただし、この表示時のパラメータ名と、設定コマンドで指定するときのパラメータが一致しないので、vusetコマンドを引数なしで叩いて、取れる引数を確認しましょう。

hammerdb>vuset
Usage: vuset [vu|delay|repeat|iterations|showoutput|logtotemp|unique|nobuff|timestamps] value

>
hammerdb>vuset vu 4

hammerdb>vuset logtotemp 1

hammerdb>vuset unique 1

hammerdb>vuset timestamps 1

disetと違い、設定変更しても、応答メッセージが全く無いですが、間違ったコマンドを投げるとエラーメッセージが帰ってくるので、無反応でプロンプトに戻ってきたら成功してます。

今回は、Virtual Userを4にしてみました。この段階でのクライアント数は、スキーマ作成時にはあった「mysql_count_ware」による制限はありません。

もう一度print vuconfして、設定変更結果を確認しておきましょう。

hammerdb>print vuconf
Virtual Users = 4
User Delay(ms) = 500
Repeat Delay(ms) = 500
Iterations = 1
Show Output = 1
Log Output = 1
Unique Log Name = 1
No Log Buffer = 0
Log Timestamps = 1

テスト実行用クライアント（Virtual user）の起動

設定に従ってクライアント（Virtual user）を起動します

hammerdb>vucreate
Vuser 1 created MONITOR - WAIT IDLE
Vuser 2 created - WAIT IDLE
Vuser 3 created - WAIT IDLE
Vuser 4 created - WAIT IDLE
Vuser 5 created - WAIT IDLE
5 Virtual Users Created with Monitor VU
vustatus can confirm this status.

hammerdb>vustatus
1 = WAIT IDLE
2 = WAIT IDLE
3 = WAIT IDLE
4 = WAIT IDLE
5 = WAIT IDLE

テストの実行

ここまできたら、ようやく実行です。

hammerdb>vurun

で実行し、終わるまで待ちます。

「Log Output = 1」にしてあれば、/tmp/にログファイルが生成されて、大量のログが出力されています。
そのファイル内の終わりの方に出てくる「TEST RESULT :」の行を確認しましょう。

実行結果の出力例

Vuser 1:TEST RESULT : System achieved 7107 MySQL TPM at 2319 NOPM

TPM = Transactions Per Minute=トランザクション数／分
NOPM = New Order Per Minute=TPC-Cのシナリオにおける新規オーダー（注文）数／分

おおよそ、「NOPM * 3 = TPM」の関係になります。

なぜTPMとNOPMという値を算出しているのかは、HammerDBのブログに書いてあります。
https://www.hammerdb.com/blog/uncategorized/why-both-tpm-and-nopm-performance-metrics/

こんな感じで、MySQLに対するTPC-Cが実行できました。

まとめ

• HammerDBのワークロード実行までの手順は、どのDBでもだいたい同じだが、パラメータ名がちょっと違う。
• GUIで設定可能なパラメータに相当する設定コマンドがあるので、それに合わせる形で設定。
• HammerDBがTPC-Cワークロードの実行結果として出力するスコアは「TPM」と「NOPM」。取り扱いに注意。

こんな感じで、各種データベースに対する具体的な設定、実行手順を見ていきます。
ちょうどよく、データベースの比較記事が掲載されていますので、今回はこちらを紹介したいと思います。

WEB+DB PRESS Vol.112