 | | | -none- | -none- 2007-10-16 - By Baron Schwartz
Back
Hi William,
William Newton wrote:
> Hello List,
>
> I have this table that has a single row in it:
>
> CREATE TABLE `quicktable` (
> `x` int(11) NOT NULL auto_increment,
> `quick_id` int(11) NOT NULL default '0',
> PRIMARY KEY (`x`)
> ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=latin1
>
> select * from quicktable;
> +---+-- ---- --+
> | x | quick_id |
> +---+-- ---- --+
> | 1 | 0 |
> +---+-- ---- --+
> 1 row in set (0.00 sec)
>
> I have a large number of connections executing these queries:
>
> BEGIN:
> SELECT quick_id FROM quicktable FOR UPDATE;
> COMMIT;
>
> This
> works well until I hit a large number of concurrent connections (around
> 200), when I start getting deadlocks. Despite the fact, that I'm only
> selecting a single table. Here is the deadlock section from SHOW INNODB
> STATUS;
>
> -- ---- ---- ---- ------
> LATEST DETECTED DEADLOCK
> -- ---- ---- ---- ------
> 071015 20:22:35
> *** (1) TRANSACTION:
> TRANSACTION 0 79790779, ACTIVE 2 sec, process no 7658, OS thread id
1185077584 starting index read
> mysql tables in use 1, locked 1
> LOCK WAIT 2 lock struct(s), heap size 368
> MySQL thread id 3961, query id 2102790 10.1.10.122 bnewton statistics
> SELECT x, quick_id FROM quicktable WHERE x=1 FOR UPDATE
> *** (1) WAITING FOR THIS LOCK TO BE GRANTED:
> RECORD
> LOCKS space id 0 page no 540674 n bits 72 index `PRIMARY` of table
> `test/quicktable` trx id 0 79790779 lock_mode X locks rec but not gap
> waiting
> Record lock, heap no 2 PHYSICAL RECORD: n_fields 4; compact format; info bits
0
> 0: len 4; hex 80000001; asc ;; 1: len 6; hex 000004c14f74; asc Ot;;
2: len 7; hex 0000098005054d;
> asc M;; 3: len 4; hex 8018f9fd; asc ;;
>
> *** (2) TRANSACTION:
> TRANSACTION 0 79790775, ACTIVE 2 sec, process no 7658, OS thread id 1191733584
> 2 lock struct(s), heap size 368
> MySQL thread id 4094, query id 2102743 10.1.10.122 bnewton
> *** (2) HOLDS THE LOCK(S):
> RECORD
> LOCKS space id 0 page no 540674 n bits 72 index `PRIMARY` of table
> `test/quicktable` trx id 0 79790775 lock_mode X locks rec but not gap
> Record lock, heap no 2 PHYSICAL RECORD: n_fields 4; compact format; info bits
0
> 0:
> len 4; hex 80000001; asc ;; 1: len 6; hex 000004c14f74; asc
> Ot;; 2: len 7; hex 0000098005054d; asc M;; 3: len 4; hex
> 8018f9fd; asc ;;
>
> *** (2) WAITING FOR THIS LOCK TO BE GRANTED:
> RECORD LOCKS space id 0 page no 540674 n bits 72 index `PRIMARY` of table
`test/quicktable`
> trx id 0 79791014 lock_mode X locks rec but not gap waiting
> Record lock, heap no 2 PHYSICAL RECORD: n_fields 4; compact format; info bits
0
> 0:
> len 4; hex 80000001; asc ;; 1: len 6; hex 000004c14f74; asc
> Ot;; 2: len 7; hex 0000098005054d; asc M;; 3: len 4; hex
> 8018f9fd; asc ;;
>
> TOO DEEP OR LONG SEARCH IN THE LOCK TABLE WAITS-FOR GRAPH
> *** WE ROLL BACK TRANSACTION (2)
>
>
> Can
> anyone explain whats going on? Is there a limit for the number of
> concurrent transactions, before looking at the lock graph becomes too
> expensive? Is that documented somewhere?
It's not documented, but yes there's both a maximum number of steps to
check for a cycle in the waits-for graph, and a maximum depth of
checking it:
http://dev.mysql.com/sources/doxygen/mysql-5 (See http://sql-5.ora-code.com).1/lock0lock_8c-source.html#l00052
00046 /* Restricts the length of search we will do in the waits-for
00047 graph of transactions */
00048 #define LOCK_MAX_N_STEPS_IN_DEADLOCK_CHECK 1000000
00049
00050 /* Restricts the recursion depth of the search we will do in the
waits-for
00051 graph of transactions */
00052 #define LOCK_MAX_DEPTH_IN_DEADLOCK_CHECK 200
This is the price you pay for instant deadlock detection, as opposed to
just lock wait timeout (the method a lot of other transactional systems
take). You could recompile with a higher number if you want. It would
be nice if this were configurable; you could submit a feature request
for that.
Baron
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=mysql@(protected)
|
|
|