5

I'm trying to run the MySQL DBT2 Benchmark Tool, I have unzipped the archive and run the following commands:

./configure --with-mysql
make
make install
mkdir /tmp/dbt
datagen -w 3 -d /tmp/dbt --mysql
scripts/mysql/mysql_load_db.sh --path /tmp/dbt --mysql-path /usr/bin/mysql
scripts/run_mysql.sh --connections 20 --time 300 --warehouses 3

But got the following output:

...

Stage 3. Starting of the test. Duration of the test 300 sec
STARTING DRIVER COMMAND:   /root/dbt2-0.37.50.3/src/driver -d 127.0.0.1 -l 300 -wmin 1 -wmax 3 -spread 1 -w 3 -sleep 300 -tpw 10 -outdir /root/output/14/driver -p 30000 -warmup 0 -cooldown 20 -intermediate_timer_resolution 0
Shutdown clients. Send TERM signal to 5154.
Shutdown driver. Send TERM signal to 5190.

Stage 4. Processing of results...
                         Response Time (s)
 Transaction      %    Average :    90th %        Total        Rollbacks      %
------------  -----  ---------------------  -----------  ---------------  -----
    Delivery   0.00          N/A                      0                0  100.00
   New Order   0.00          N/A                      0                0  100.00
Order Status   0.00          N/A                      0                0  100.00
     Payment   0.00          N/A                      0                0  100.00
 Stock Level   0.00          N/A                      0                0  100.00

0.00 new-order transactions per minute (NOTPM)
0.0 minute duration
0 total unknown errors
0.00 rollback transactions
0 second(s) ramping up

scripts/run_mysql.sh: line 632:  5154 Killed                  nohup $CLIENT_COMMAND > $OUTPUT_DIR/client.out 2>&1
scripts/run_mysql.sh: line 632:  5190 Killed                  nohup $DRIVER_COMMAND > $OUTPUT_DIR/driver.out 2>&1
Test completed.

During the execution, SHOW PROCESSLIST did show that 20 clients were connected, all sleeping.

Any idea why no transactions are executed?

2
  • since no one else wants to take the question, I'm going to go through the same steps on a clean centos install using whatever MySQL 5 comes with 6.4. Jul 30, 2013 at 8:51
  • any output in $OUTPUT_DIR/client.out or $OUTPUT_DIR/driver.out 2>&1 ?
    – redguy
    Aug 1, 2013 at 9:48

1 Answer 1

6
+100

I have done the following to reproduce the output you are seeing from dbt2.

  1. Installed Centos6.4

  2. Installed MySQL 5.1.69 via YUM

  3. Installed Innotop to view in real time all queries and open transactions

Ran the bench as you did:

[root@centos-cef dbt2-0.37.50.3]# scripts/run_mysql.sh --connections 20 --terminals 5 --time 300 --warehouses 3 --verbose

Innotop only showed 20 active clients but no open queries or transactions

DBT2 provides several logs. On the system I used for testing, there was a main directory /root/output and then a number for each execution.

/root/output/N where N is the execution number.

In the file /root/output/3/client/error.log, I found the following information

Tue Jul 30 16:57:23 2013
Microseconds : 998724
tid:-1511446784 mysql/dbc_payment.c:32
mysql reports SQL STMT: stmt ERROR: 1305 PROCEDURE dbt2.payment does not exist
Tue Jul 30 16:57:23 2013
Microseconds : 998753
tid:-1511446784 mysql/dbc_common.c:97
ROLLBACK INITIATED

Tue Jul 30 16:57:28 2013
Microseconds : 859693
tid:-1511713024 mysql/dbc_new_order.c:88
mysql reports: SQL: call new_order(2, 5, 984, 1, 9, 90056, 2, 8, 47872, 2, 3, 48592, 2, 7, 21925, 2,                                 7, 96574, 2, 5, 53239, 2, 8, 30640, 2, 4, 39619, 2, 10, 86015, 2, 8,                                 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,                          0, 0, @rc),  ERROR: 1305 PROCEDURE dbt2.new_order does not exist
Tue Jul 30 16:57:28 2013
Microseconds : 859735
tid:-1511713024 mysql/dbc_common.c:97
ROLLBACK INITIATED

I'm seeing ROLLBACK INITIATED throughout the log. I am also seeing that certain stored procedures are not installed such as dbt2.payment

So I looked a little further and there is another script that has to be run in order to create the stored procedures in the dbt2 database.

scripts/mysql/mysql_load_sp.sh --database dbt2 --client-path /usr/bin/

Which gives the following output:

Load SP: delivery
Load SP: new_order
Load SP: new_order_2
Load SP: order_status
Load SP: payment
Load SP: stock_level

Have you run

scripts/mysql/mysql_load_sp.sh --database dbt2 --client-path /usr/bin 

on your server to load in the stored procedures?

After loading in DBT2's stored procedures, I ran DBT2 again and this time I did see transactions in Innotop's output

[RO] InnoDB Txns (? for help)                             localhost, 2h7m, InnoDB 1s :-), 765.68 QPS, 22/0/0 con/run/cac thds, 5.1.69

History  Versions  Undo  Dirty Buf  Used Bufs  Txns  MaxTxnTime  LStrcts
      6       102  0 0       1.56%     99.80%    21       00:00         

ID   User  Host       Txn Status  Time   Undo  Query Text
217  root  localhost  COMMITTED   00:00     0  COMMIT    

I noticed though as you did, that DBT2's output was still showing O's everywhere, so I increased the number of warehouses to 30. My thinking was that there wasn't enough transactions or activity to generate useful results

scripts/run_mysql.sh --connections 20 --time 300 --warehouses 30 --verbose

Stage 4. Processing of results...
                         Response Time (s)
 Transaction      %    Average :    90th %        Total        Rollbacks      %
------------  -----  ---------------------  -----------  ---------------  -----
    Delivery   3.32      0.004 :     0.001          136                0   0.00
   New Order  44.59      0.027 :     0.095         1826             1654  90.58
Order Status   4.20      0.002 :     0.001          172                0   0.00
     Payment  42.86      0.007 :     0.014         1755                0   0.00
 Stock Level   3.57      0.010 :     0.000          146                0   0.00

And as you can see, DBT2 sent back appropriate results this time.

2
  • The missing stored procedures was indeed the problem. This is curious though, as the README says "optional, only if you ran configure with --enable-mysql-sp". One of the stored procedures had a field too short as well, resulting in many rollbacks (out_w_city in the payment SP). Fixed this, and it now works.
    – BenMorel
    Aug 1, 2013 at 13:25
  • @Benjamin - definitely enjoyed working on this question. It was the various logs and files in /root/output that lead to the solution. Aug 1, 2013 at 13:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.