Percona pt-deadlock-logger не обнаруживает взаимоблокировки

На сервере с проблемами производительности я пытаюсь обнаружить взаимоблокировки с помощью pt-deadlock-logger Percona



У меня есть эта строка в файле crontab 



0 * * * * root pt-deadlock-logger --daemonize --run-time=1h --dest D=test,t=deadlocks u=root,h=127.0.0.1


Всякий раз, когда я захожу на сервер, я могу подтвердить, что он работает с PS-ef|grep deadlock



База данных и таблица настроены. Насколько я понимаю, я использую права доступа root, основанные на пароле, установленном в /root/. my. cnf



Я попытался смоделировать тупик с помощью (отсюда: http://forums.mysql.com/read.php?10,193770,193913#msg-193913)



create table test.innodb_deadlock_maker(a int primary key) engine=innodb; 

insert into test.innodb_deadlock_maker(a) values(0), (1); 



-- connection 0 

set transaction isolation level serializable; 

start transaction; 

select * from test.innodb_deadlock_maker where a = 0; 

update test.innodb_deadlock_maker set a = 0 where a <> 0; 



-- connection 1 

set transaction isolation level serializable; 

start transaction; 

select * from test.innodb_deadlock_maker where a = 1; 

update test.innodb_deadlock_maker set a = 1 where a <> 1;


И это показывает deadloc в консоли mysql, но он не записан в таблице базы данных. Есть идеи, почему бы и нет?

685   2  

2 ответов:

Попытка симулировать тупик, как указано, привела к этому для меня: 

-- connection 0 
set transaction isolation level serializable; 
start transaction; 
select * from test.innodb_deadlock_maker where a = 0;
-- does not block, fails immediately with 
-- ERROR 1062 (23000): Duplicate entry '0' for key 'PRIMARY'
update test.innodb_deadlock_maker set a = 0 where a <> 0; 

-- connection 1 
set transaction isolation level serializable; 
start transaction; 
select * from test.innodb_deadlock_maker where a = 1; 
-- does block, fails after a timeout with
-- ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
update test.innodb_deadlock_maker set a = 1 where a <> 1;

Итак, соединение 1 ожидает соединения 0, но соединение 0 не ждет соединения 1, только COMMIT или ROLLBACK из приложения.

Это не тупик, и SHOW ENGINE INNODB STATUS также не сообщает о тупике.

Изменение последовательности на: 

-- connection 0 
set transaction isolation level serializable; 
start transaction; 
select * from test.innodb_deadlock_maker where a = 0;

-- connection 1 
set transaction isolation level serializable; 
start transaction; 
select * from test.innodb_deadlock_maker where a = 1; 

-- connection 0 
-- does block, waiting on connection 1
update test.innodb_deadlock_maker set a = 0 where a <> 0; 

-- connection 1 
-- would deadlock, fails immediately with
-- ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting
update test.innodb_deadlock_maker set a = 1 where a <> 1;

И это разблокирует соединение 0: 

-- connection 0 
update test.innodb_deadlock_maker set a = 0 where a <> 0; 
-- now unblocked, fails with
-- ERROR 1062 (23000): Duplicate entry '0' for key 'PRIMARY'

В этом случае SHOW ENGINE INNODB STATUS сообщает: 

LATEST DETECTED DEADLOCK
------------------------
2013-10-03 11:57:27 0x7f6b60308700
*** (1) TRANSACTION:
TRANSACTION 1297, ACTIVE 47 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 5 lock struct(s), heap size 1160, 3 row lock(s)
MySQL thread id 2, OS thread handle 140099372304128, query id 13 localhost root Searching rows for update
update test.innodb_deadlock_maker set a = 0 where a <> 0
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 8 page no 3 n bits 72 index `PRIMARY` of table `test`.`innodb_deadlock_maker` trx id 1297 lock_mode X waiting
Record lock, heap no 3 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 4; hex 80000001; asc     ;;
 1: len 6; hex 000000000508; asc       ;;
 2: len 7; hex a80000011a011c; asc        ;;

*** (2) TRANSACTION:
TRANSACTION 1298, ACTIVE 15 sec starting index read
mysql tables in use 1, locked 1
4 lock struct(s), heap size 1160, 2 row lock(s)
MySQL thread id 3, OS thread handle 140099152021248, query id 14 localhost root Searching rows for update
update test.innodb_deadlock_maker set a = 1 where a <> 1
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 8 page no 3 n bits 72 index `PRIMARY` of table `test`.`innodb_deadlock_maker` trx id 1298 lock mode S locks rec but not gap
Record lock, heap no 3 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 4; hex 80000001; asc     ;;
 1: len 6; hex 000000000508; asc       ;;
 2: len 7; hex a80000011a011c; asc        ;;

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 8 page no 3 n bits 72 index `PRIMARY` of table `test`.`innodb_deadlock_maker` trx id 1298 lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 4; hex 80000000; asc     ;;
 1: len 6; hex 000000000508; asc       ;;
 2: len 7; hex a80000011a0110; asc        ;;

*** WE ROLL BACK TRANSACTION (2)

Я не могу говорить с pt-deadlock-logger, но я думаю, что он опирается на раздел LATEST DETECTED DEADLOCK в SHOW ENGINE INNODB STATUS, поэтому сначала убедитесь, что эта команда действительно сообщает о тупике.

2  
2013-10-03 11:24:41

Я не отвечаю прямо на ваш вопрос. Но pt-deadlock-logger не нужно добавлять в crontab вообще.

После запуска pt-deadlock-logger, если не указано --run-time, pt-deadlock-logger работает вечно, проверяя наличие взаимоблокировок на каждом интервале. И вы также можете указать интервал с помощью опции-интервал. Для получения дополнительной информации, пожалуйста, проверьте ссылку под.

Https://www.percona.com/doc/percona-toolkit/2.1/pt-deadlock-logger.html#cmdoption-pt-deadlock-logger--interval

1  
2015-11-24 04:12:50

Comments

    Ничего не найдено.
Click here to cancel reply.