This TPC-C style benchmark run was performed by the "" driver of BenchmarkSQL version .
|
| Transaction Type |
Latency | Count | Percent | Rollback | Errors | Skipped Deliveries |
||
|---|---|---|---|---|---|---|---|---|
| 90th % | Avg | Max | ||||||
| Overall tpmC: | |
| Overall tpmTotal: |
The TPC-C specification has an theoretical maximum of 12.86 NEW_ORDER transactions per minute per warehouse. In reality this value cannot be reached because it would require a perfect mix with 45% of NEW_ORDER transactions and a ZERO response time from the System under Test including the database.
The above tpmC of is of that theoretical maximum for a database with warehouses.
tpmC is the number of NEW_ORDER Transactions, that where processed
per minute. tpmTOTAL is the number of Transactions processed per
minute for all transaction types, but without the background part
of the DELIVERY transaction.
| Overall Average CPU Utilization |
|---|
Note:In the graph below the percentages for User, System and IOWait CPU time are stacked
on top of each other.
We track the number of dirty kernel buffers, as measured by
the "nr_dirty" line in /proc/vmstat, to be able to correlate
IO problems with when the kernel's IO schedulers are flushing
writes to disk. A write(2) system call does not immediately
cause real IO on a storage device. The data written is just
copied into a kernel buffer. Several tuning parameters control
when the OS is actually transferring these dirty buffers to
the IO controller(s) in order to eventually get written to
real disks (or similar).