1. unzip the deadlock.7zip
2. start test with "sh run.sh" to observe the results of perf data.
3. apply the patch and turn the switch off to get the result again:
root@(none) 03:40:33>show variables like '%detect%';
+------------------------+-------+
| Variable_name | Value |
+------------------------+-------+
| innodb_deadlock_detect | OFF |
+------------------------+-------+
1 row in set (0.00 sec)
The result we test is summarized as:
1000000 queries, concurrency=16
2124 vs 1971 seconds,
1000000 queries, concurrency=700
33569 vs 2612 seconds
As we can see, the patched switch promoted the perf much for the large concurrency scenario.
Steps to run:
1. unzip the deadlock.7zip
2. start test with "sh run.sh" to observe the results of perf data.
3. apply the patch and turn the switch off to get the result again:
root@(none) 03:40:21>set global innodb_ deadlock_ detect= off;
Query OK, 0 rows affected (0.00 sec)
root@(none) 03:40:33>show variables like '%detect%'; ------- ------- ----+-- -----+ ------- ------- ----+-- -----+ deadlock_ detect | OFF | ------- ------- ----+-- -----+
+------
| Variable_name | Value |
+------
| innodb_
+------
1 row in set (0.00 sec)
The result we test is summarized as:
1000000 queries, concurrency=16
2124 vs 1971 seconds,
1000000 queries, concurrency=700
33569 vs 2612 seconds
As we can see, the patched switch promoted the perf much for the large concurrency scenario.