My previous benchmark on Performance Schema was mainly in memory workload and against single tables.
Now after adding multi-tables support to sysbench, it is interesting to see what statistic we can get from workload that produces some disk IO.
So let’s run sysbench against 100 tables, each 5000000 rows (~1.2G ) and buffer pool 30G.
The scripts and results are on Benchmark Wiki.
If we look on performance overhead it appears rather big in read-only benchmark, and it is well explained in Dimitri’s post, so let’s keep this question aside and wait on further 5.6 releases with fixes.
Now I am going to post some statistics we are able to get from performance schema tables.
1. table_io_waits_summary_by_table
|
1 |
<br>mysql> select * from table_io_waits_summary_by_table where OBJECT_NAME='sbtest55' G<br>*************************** 1. row ***************************<br> OBJECT_TYPE: TABLE<br> OBJECT_SCHEMA: sbtest<br> OBJECT_NAME: sbtest55<br> COUNT_STAR: 1806932<br> SUM_TIMER_WAIT: 23771749557590<br> MIN_TIMER_WAIT: 83266<br> AVG_TIMER_WAIT: 13155501<br> MAX_TIMER_WAIT: 84087466520<br> COUNT_READ: 1789764<br> SUM_TIMER_READ: 17671510276755<br> MIN_TIMER_READ: 83266<br> AVG_TIMER_READ: 9873345<br> MAX_TIMER_READ: 84087466520<br> COUNT_WRITE: 17168<br> SUM_TIMER_WRITE: 6100239280835<br> MIN_TIMER_WRITE: 7587746<br> AVG_TIMER_WRITE: 355326061<br> MAX_TIMER_WRITE: 78153671549<br> COUNT_FETCH: 1789764<br> SUM_TIMER_FETCH: 17671510276755<br> MIN_TIMER_FETCH: 83266<br> AVG_TIMER_FETCH: 9873345<br> MAX_TIMER_FETCH: 84087466520<br> COUNT_INSERT: 4292<br>SUM_TIMER_INSERT: 1343751174852<br>MIN_TIMER_INSERT: 31913539<br>AVG_TIMER_INSERT: 313082268<br>MAX_TIMER_INSERT: 57121140547<br> COUNT_UPDATE: 8584<br>SUM_TIMER_UPDATE: 3453842535354<br>MIN_TIMER_UPDATE: 7587746<br>AVG_TIMER_UPDATE: 402357649<br>MAX_TIMER_UPDATE: 78153671549<br> COUNT_DELETE: 4292<br>SUM_TIMER_DELETE: 1302645570629<br>MIN_TIMER_DELETE: 18127219<br>AVG_TIMER_DELETE: 303505097<br>MAX_TIMER_DELETE: 62494969560<br> |
Or using this data we can TOP 5 accessed tables via
|
1 |
<br>mysql> select OBJECT_NAME,COUNT_STAR from table_io_waits_summary_by_table order by COUNT_STAR DESC LIMIT 5;<br>+-------------+------------+<br>| OBJECT_NAME | COUNT_STAR |<br>+-------------+------------+<br>| sbtest97 | 1854084 |<br>| sbtest66 | 1837665 |<br>| sbtest56 | 1834297 |<br>| sbtest44 | 1829666 |<br>| sbtest47 | 1825035 |<br>+-------------+------------+<br>5 rows in set (0.01 sec)<br> |
2. There is table with statistic per index:
|
1 |
<br>mysql> select * from table_io_waits_summary_by_index_usage where OBJECT_NAME='sbtest55'G<br>*************************** 1. row ***************************<br> OBJECT_TYPE: TABLE<br> OBJECT_SCHEMA: sbtest<br> OBJECT_NAME: sbtest55<br> INDEX_NAME: PRIMARY<br> COUNT_STAR: 1789764<br> SUM_TIMER_WAIT: 17671510276755<br> MIN_TIMER_WAIT: 83266<br> AVG_TIMER_WAIT: 9873345<br> MAX_TIMER_WAIT: 84087466520<br> COUNT_READ: 1789764<br> SUM_TIMER_READ: 17671510276755<br> MIN_TIMER_READ: 83266<br> AVG_TIMER_READ: 9873345<br> MAX_TIMER_READ: 84087466520<br> COUNT_WRITE: 0<br> SUM_TIMER_WRITE: 0<br> MIN_TIMER_WRITE: 0<br> AVG_TIMER_WRITE: 0<br> MAX_TIMER_WRITE: 0<br> COUNT_FETCH: 1789764<br> SUM_TIMER_FETCH: 17671510276755<br> MIN_TIMER_FETCH: 83266<br> AVG_TIMER_FETCH: 9873345<br> MAX_TIMER_FETCH: 84087466520<br> COUNT_INSERT: 0<br>SUM_TIMER_INSERT: 0<br>MIN_TIMER_INSERT: 0<br>AVG_TIMER_INSERT: 0<br>MAX_TIMER_INSERT: 0<br> COUNT_UPDATE: 0<br>SUM_TIMER_UPDATE: 0<br>MIN_TIMER_UPDATE: 0<br>AVG_TIMER_UPDATE: 0<br>MAX_TIMER_UPDATE: 0<br> COUNT_DELETE: 0<br>SUM_TIMER_DELETE: 0<br>MIN_TIMER_DELETE: 0<br>AVG_TIMER_DELETE: 0<br>MAX_TIMER_DELETE: 0<br>*************************** 3. row ***************************<br> OBJECT_TYPE: TABLE<br> OBJECT_SCHEMA: sbtest<br> OBJECT_NAME: sbtest55<br> INDEX_NAME: NULL<br> COUNT_STAR: 17168<br> SUM_TIMER_WAIT: 6100239280835<br> MIN_TIMER_WAIT: 7587746<br> AVG_TIMER_WAIT: 355326061<br> MAX_TIMER_WAIT: 78153671549<br> COUNT_READ: 0<br> SUM_TIMER_READ: 0<br> MIN_TIMER_READ: 0<br> AVG_TIMER_READ: 0<br> MAX_TIMER_READ: 0<br> COUNT_WRITE: 17168<br> SUM_TIMER_WRITE: 6100239280835<br> MIN_TIMER_WRITE: 7587746<br> AVG_TIMER_WRITE: 355326061<br> MAX_TIMER_WRITE: 78153671549<br> COUNT_FETCH: 0<br> SUM_TIMER_FETCH: 0<br> MIN_TIMER_FETCH: 0<br> AVG_TIMER_FETCH: 0<br> MAX_TIMER_FETCH: 0<br> COUNT_INSERT: 4292<br>SUM_TIMER_INSERT: 1343751174852<br>MIN_TIMER_INSERT: 31913539<br>AVG_TIMER_INSERT: 313082268<br>MAX_TIMER_INSERT: 57121140547<br> COUNT_UPDATE: 8584<br>SUM_TIMER_UPDATE: 3453842535354<br>MIN_TIMER_UPDATE: 7587746<br>AVG_TIMER_UPDATE: 402357649<br>MAX_TIMER_UPDATE: 78153671549<br> COUNT_DELETE: 4292<br>SUM_TIMER_DELETE: 1302645570629<br>MIN_TIMER_DELETE: 18127219<br>AVG_TIMER_DELETE: 303505097<br>MAX_TIMER_DELETE: 62494969560<br>3 rows in set (0.03 sec)<br> |
Interesting that UPDATE/DELETE operations are not counted in INDEX_NAME: PRIMARY,
the documentation says: “Inserts are counted against INDEX_NAME = NULL”, but
it does not mention UPDATEs and DELETEs.
3. Beside logical access to tables, we can see physical IO to files:
|
1 |
<br>select * from file_summary_by_instance where FILE_NAME like '%sbtest55%' limit 5G<br>*************************** 1. row ***************************<br> FILE_NAME: /data/tachion/sb/sbtest/sbtest55.ibd<br> EVENT_NAME: wait/io/file/innodb/innodb_data_file<br> COUNT_READ: 22071<br> COUNT_WRITE: 19916<br> SUM_NUMBER_OF_BYTES_READ: 361611264<br>SUM_NUMBER_OF_BYTES_WRITE: 326303744<br> |
or we can get top tables that required read IO
|
1 |
<br>mysql> select * from file_summary_by_instance order by COUNT_READ desc limit 6G<br>*************************** 1. row ***************************<br> FILE_NAME: /data/tachion/sb/ibdata1<br> EVENT_NAME: wait/io/file/innodb/innodb_data_file<br> COUNT_READ: 118218<br> COUNT_WRITE: 849692<br> SUM_NUMBER_OF_BYTES_READ: 1936883712<br>SUM_NUMBER_OF_BYTES_WRITE: 103557693440<br>*************************** 2. row ***************************<br> FILE_NAME: /data/tachion/sb/sbtest/sbtest95.ibd<br> EVENT_NAME: wait/io/file/innodb/innodb_data_file<br> COUNT_READ: 22947<br> COUNT_WRITE: 20646<br> SUM_NUMBER_OF_BYTES_READ: 375963648<br>SUM_NUMBER_OF_BYTES_WRITE: 338264064<br>*************************** 3. row ***************************<br> FILE_NAME: /data/tachion/sb/sbtest/sbtest53.ibd<br> EVENT_NAME: wait/io/file/innodb/innodb_data_file<br> COUNT_READ: 22617<br> COUNT_WRITE: 20282<br> SUM_NUMBER_OF_BYTES_READ: 370556928<br>SUM_NUMBER_OF_BYTES_WRITE: 332300288<br>*************************** 4. row ***************************<br> FILE_NAME: /data/tachion/sb/sbtest/sbtest92.ibd<br> EVENT_NAME: wait/io/file/innodb/innodb_data_file<br> COUNT_READ: 22507<br> COUNT_WRITE: 19160<br> SUM_NUMBER_OF_BYTES_READ: 368754688<br>SUM_NUMBER_OF_BYTES_WRITE: 313917440<br>*************************** 5. row ***************************<br> FILE_NAME: /data/tachion/sb/sbtest/sbtest35.ibd<br> EVENT_NAME: wait/io/file/innodb/innodb_data_file<br> COUNT_READ: 22406<br> COUNT_WRITE: 20938<br> SUM_NUMBER_OF_BYTES_READ: 367099904<br>SUM_NUMBER_OF_BYTES_WRITE: 343048192<br>*************************** 6. row ***************************<br> FILE_NAME: /data/tachion/sb/sbtest/sbtest97.ibd<br> EVENT_NAME: wait/io/file/innodb/innodb_data_file<br> COUNT_READ: 22378<br> COUNT_WRITE: 20512<br> SUM_NUMBER_OF_BYTES_READ: 366641152<br>SUM_NUMBER_OF_BYTES_WRITE: 336068608<br>6 rows in set (0.00 sec)<br> |
Interesting that top tables that required IO are not the same that most accessed.
I am looking to run the same benchmark in coming 5.6 releases when performance overhead is fixed.