System achieved 0 NOPM -- how to diagnose?

[mdedlow]

I used hammerdb successfully a dozen runs or so with good results, but now I get this "0 NOPM" result. It must be something simple and dumb on my part, but I am stumped. Can anyone help?

dbset db ora
dbset bm TPC-C
diset connection instance TPCC
diset tpcc tpcc_user TPCC2
diset tpcc tpcc_pass ...
diset tpcc ora_driver timed
diset tpcc total_iterations 10000000
diset tpcc rampup 2
diset tpcc duration 5
loadscript
vuset unique 1
vuset logtotemp 1
vuset showoutput 1
vuset vu 2
vucreate
vurun
vudestroy

./hammerdbcli auto oracle.tcl
HammerDB CLI v4.6
Copyright (C) 2003-2022 Steve Shaw
Type "help" for a list of commands
Initialized SQLite on-disk database /tmp/hammer.DB using existing tables (405,504 KB)
Database set to Oracle
Benchmark set to TPC-C for Oracle
Value TPCC for connection:instance is the same as existing value TPCC, no change made
Value TPCC2 for tpcc:tpcc_user is the same as existing value TPCC2, no change made
Value timed for tpcc:ora_driver is the same as existing value timed, no change made
Value 10000000 for tpcc:total_iterations is the same as existing value 10000000, no change made
Value 2 for tpcc:rampup is the same as existing value 2, no change made
Value 5 for tpcc:duration is the same as existing value 5, no change made
Script loaded, Type "print script" to view
Vuser 1 created MONITOR - WAIT IDLE
Vuser 2 created - WAIT IDLE
Vuser 3 created - WAIT IDLE
Logging activated
to /tmp/hammerdb_63A3E4825F0603E213836313.log
3 Virtual Users Created with Monitor VU
Vuser 1:RUNNING
Vuser 2:RUNNING
Vuser 3:RUNNING
Vuser 1:Beginning rampup time of 2 minutes
Vuser 2:Processing 10000000 transactions with output suppressed...
Vuser 3:Processing 10000000 transactions with output suppressed...
Vuser 1:Rampup 1 minutes complete ...
Vuser 1:Rampup 2 minutes complete ...
Vuser 1:Rampup complete, Taking start AWR snapshot.
Vuser 1:Start Snapshot 84 taken at 22 DEC 2022 05:02 of instance DB1220 (1) of database DB1220 (4072513538)
Vuser 1:Timing test period of 5 in minutes
Vuser 1:1 ...,
Vuser 1:2 ...,
Vuser 1:3 ...,
Vuser 1:4 ...,
Vuser 1:5 ...,
Vuser 1:Test complete, Taking end AWR snapshot.
Vuser 1:End Snapshot 85 taken at 22 DEC 2022 05:07 of instance DB1220 (1) of database DB1220 (4072513538)
Vuser 1:Test complete: view report from SNAPID 84 to 85
Vuser 1:2 Active Virtual Users configured
Vuser 1:TEST RESULT : System achieved 0 NOPM from 2 Oracle TPM
Vuser 1:FINISHED SUCCESS
Vuser 3:FINISHED SUCCESS
Vuser 2:FINISHED SUCCESS
ALL VIRTUAL USERS COMPLETE
vudestroy success
Shutting down HammerDB CLI

[sm-shaw]

First of all do a print dict and check that the keyandthink value is not set to true.
If for example you tried asynchronous clients it will automatically set it for you.
With keyandthink you would expect about 1 NOPM per connection.
Otherwise check the AWR report 84 to 85 to see the top timed events.

[mdedlow]

I discovered setting: diset tpcc raiseerror true. This revealed Oracle error (can't extend extent).

False seems like an odd default setting for this. Is there a common use case where one does not want to know that the virtual user encountered database errors?

[sm-shaw]

Yes, for example if a deadlock is encountered you want the transaction to be aborted but not stop the virtual user completely so by default terminating on an error is false. Usually you would have fully tested your environment with a "test the tests" approach first before running measured tests and therefore not raising errors is the correct default.

[mdedlow]

I did "test the tests", and ran several dozen benchmarks successfully. But conditions change. I ran this on a fresh OCI db, which I discovered only allocates 32GB to USERS tablespace, and so after a few dozen hammerdb runs, there was no space left.

It seems like a "logdberror" option (not abort) might be useful. I think knowing that deadlocks are happening would be valuable too.

Thanks.

[sm-shaw]

Yes, a valid point. I have checked and for Oracle we don't report anything if RAISEERROR is not set:

 if { $RAISEERROR } {
                    error "Delivery : $message [ oramsg $curn_dl all ]"
                } else {
                    ;
                }

However for other databases e.g,. MySQL we do:

  if { $RAISEERROR } {
                    error "Delivery : $mysqlstatus(message)"
                } else { 
                   puts $mysqlstatus(message) 
                } 

So, for the same behaviour for Oracle it would be:

 if { $RAISEERROR } {
                    error "Delivery : $message [ oramsg $curn_dl all ]"
                } else {
                    puts "$message [ oramsg $curn_dl all ]"
                }

Feel free to submit a pull request if you would like to see this change.