Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.7.3, 10.7.4, 10.8.2, 10.6.8, 10.8.3, 10.9.1
-
None
Description
In MariaDB (as well as in MySQL 8), we have no wait event instrumentation for record locks and for table locks.
As such, table and row lock waits are reported incorrectly as "wait/io/table/sql/handler".
This makes performance troubleshooting impossible for customers.
The expected outcome is to create 2 more instruments: row lock and table lock. These 2 types of lock waits can then be measured inside performance_schema. Being able to separate lock waits from IO waits will aid performance tuning, because reducing them will require difference approaches.
Table and row lock instrumentation maybe too resource intensive. In the meantime, the fix in https://github.com/MariaDB/server/pull/2206 marks this kind of wait as wait/lock/table/sql/handler
Steps to reproduce:
- Add the following line into my.cnf before instance start
performance_schema=ON - Run the following to set up all consumers and instrumentation
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES';UPDATE performance_schema.setup_instruments SET ENABLED = 'YES', TIMED = 'YES';set global innodb_lock_wait_timeout=7200; - Set up test table
create database test;use testcreate table t1 (id1 int(11), col1 varchar (200));insert into t1 values (1, 'aa');insert into t1 values (2, 'bb'); - Run 3 concurrent sessions to observe the bug
- Session 1
start transaction;select id1 from test.t1 where id1=1 for update;select sleep(100000); - Session 2
start transaction;select id1 from test.t1 where id1=1 for update; - Session 3
MariaDB [test]> select * from performance_schema.threads where type = 'foreground'\G*************************** Only relevant row displayed below ***************************THREAD_ID: 12NAME: thread/sql/one_connectionTYPE: FOREGROUNDPROCESSLIST_ID: 4PROCESSLIST_USER: haidongPROCESSLIST_HOST: NULLPROCESSLIST_DB: NULLPROCESSLIST_COMMAND: QueryPROCESSLIST_TIME: 9PROCESSLIST_STATE: Sending dataPROCESSLIST_INFO: select id1 from test.t1 where id1=1 for updatePARENT_THREAD_ID: 1ROLE: NULLINSTRUMENTED: YESHISTORY: YESCONNECTION_TYPE: SocketTHREAD_OS_ID: 22508Â
MariaDB [test]> select * from performance_schema.events_waits_current where thread_id=12\G*************************** 1. row ***************************THREAD_ID: 12EVENT_ID: 236END_EVENT_ID: NULLEVENT_NAME: wait/io/table/sql/handler <<<Incorrect instrument nameSOURCE:TIMER_START: 767747433709600TIMER_END: 791300625915200TIMER_WAIT: 23553192205600SPINS: NULLOBJECT_SCHEMA: testOBJECT_NAME: t1INDEX_NAME: NULLOBJECT_TYPE: TABLEOBJECT_INSTANCE_BEGIN: 139905003640240NESTING_EVENT_ID: 235NESTING_EVENT_TYPE: STAGEOPERATION: fetchNUMBER_OF_BYTES: 47FLAGS: NULL1 row in set (0.001 sec)
- Session 1
I'm working on a fix.