MySQL Bugs: #37600: Implement SHOW ENGINE FALCON STATUS, SHOW ENGINE FALCON MUTEX

Bug #37600	Implement SHOW ENGINE FALCON STATUS, SHOW ENGINE FALCON MUTEX
Submitted:	24 Jun 2008 1:49	Modified:	26 May 2010 17:50
Reporter:	Mark Callaghan	Email Updates:
Status:	Unsupported	Impact on me:	None
Category:	MySQL Server: Falcon storage engine	Severity:	S4 (Feature request)
Version:	6.0.5	OS:	Any
Assigned to:		CPU Architecture:	Any
Tags:	engine, F_NEW FEATURE, falcon, show

Description:
These commands have not been implemented:
SHOW ENGINE FALCON STATUS
SHOW ENGINE FALCON MUTEX

Given the need for users to debug and understand Falcon, it would be nice to provide these.

How to repeat:
NA

Mark, I totally agree with your request. Here is what you can do in the meantime to enable the printing of the locks:

1. Set falcon_debug_mask to 2 and Falcon will print debug output for the deadlock in the error log shortly after the deadlock occurs. This is a dynamic variable that can be set at any time.

2. If you are examining an existing deadlock and do not wish to wait, set the falcon_debug_mask variable, then break in with gdb, find a thread that is deadlocked, move to the SyncObject frame and issue "call stalled(thread)" to force the printing of the debug output.

I hope this helps!

Phillip,
Calling stalled(thread) would be easier to do if optimized falcon builds used -g as the rest of MySQL does.

Output with falcon_debug_mask=2
Stalled threads
  Thread 0xb2e78ba8 (-755586128) sleep=0, grant=0, locks=1, who 0, parent=(nil)
    Pending Table::validateAndInsert state 0 (1) syncObject 0xf435d2b8
  Thread 0xf40184a0 (-755385424) sleep=0, grant=0, locks=1, who 0, parent=(nil)
    Pending Table::validateAndInsert state 0 (1) syncObject 0xf435d2b8
  Thread 0xb2e78ef0 (-755786832) sleep=1, grant=0, locks=1, who 0, parent=(nil)
    Pending Table::validateAndInsert state 0 (1) syncObject 0xf435d2b8
  Thread 0xf401c608 (-143410256) sleep=1, grant=0, locks=1, who 0, parent=(nil)
    Pending Table::validateAndInsert state 0 (1) syncObject 0xf435d2b8
Stalled synchronization objects:
  SyncObject f435d2b8: state 1, monitor 0, waiters 4
    Waiting thread b2e78ba8 (-755586128), type 1; Table::validateAndInsert
    Waiting thread f40184a0 (-755385424), type 1; Table::validateAndInsert
    Waiting thread b2e78ef0 (-755786832), type 1; Table::validateAndInsert
    Waiting thread f401c608 (-143410256), type 1; Table::validateAndInsert
------------------------------------
Stalled threads
  Thread 0xf4009608 (-738116688) sleep=0, grant=0, locks=1, who 0, parent=0xf3ffd890
    Pending RecordLeaf::retireRecords2 state 0 (1) syncObject 0xf435d680
Stalled synchronization objects:
  SyncObject f435d680: state 1, monitor 0, waiters 1
    Waiting thread f4009608 (-738116688), type 1; RecordLeaf::retireRecords2
------------------------------------
------------------------------------
Stalled threads
  Thread 0xf40184a0 (-755385424) sleep=0, grant=0, locks=1, who 0, parent=(nil)
    Pending Table::validateAndInsert state 0 (1) syncObject 0xf435d2b8
  Thread 0xb2e78ba8 (-755586128) sleep=1, grant=0, locks=1, who 0, parent=(nil)
    Pending Table::validateAndInsert state 0 (1) syncObject 0xf435d2b8
  Thread 0xb2e78ef0 (-755786832) sleep=1, grant=0, locks=1, who 0, parent=(nil)
    Pending Table::validateAndInsert state 0 (1) syncObject 0xf435d2b8
  Thread 0xf401c608 (-143410256) sleep=1, grant=0, locks=1, who 0, parent=(nil)
    Pending Table::validateAndInsert state 0 (1) syncObject 0xf435d2b8
Stalled synchronization objects:
  SyncObject f435d2b8: state 1, monitor 0, waiters 4
    Waiting thread b2e78ba8 (-755586128), type 1; Table::validateAndInsert
    Waiting thread f40184a0 (-755385424), type 1; Table::validateAndInsert
    Waiting thread b2e78ef0 (-755786832), type 1; Table::validateAndInsert
    Waiting thread f401c608 (-143410256), type 1; Table::validateAndInsert
------------------------------------
Stalled threads
  Thread 0xb2e78ef0 (-755786832) sleep=0, grant=0, locks=1, who 0, parent=(nil)
    Pending Table::validateAndInsert state 0 (1) syncObject 0xf435d2b8
  Thread 0xb2e78ba8 (-755586128) sleep=1, grant=0, locks=1, who 0, parent=(nil)
    Pending Table::validateAndInsert state 0 (1) syncObject 0xf435d2b8
  Thread 0xf40184a0 (-755385424) sleep=1, grant=0, locks=1, who 0, parent=(nil)
    Pending Table::validateAndInsert state 0 (1) syncObject 0xf435d2b8
  Thread 0xf401c608 (-143410256) sleep=1, grant=0, locks=1, who 0, parent=(nil)
    Pending Table::validateAndInsert state 0 (1) syncObject 0xf435d2b8
Stalled synchronization objects:
  SyncObject f435d2b8: state 1, monitor 0, waiters 4
    Waiting thread b2e78ba8 (-755586128), type 1; Table::validateAndInsert
    Waiting thread f40184a0 (-755385424), type 1; Table::validateAndInsert
    Waiting thread b2e78ef0 (-755786832), type 1; Table::validateAndInsert
    Waiting thread f401c608 (-143410256), type 1; Table::validateAndInsert
------------------------------------
Stalled threads
  Thread 0xf401c608 (-143410256) sleep=0, grant=0, locks=1, who 0, parent=(nil)
    Pending Table::validateAndInsert state 0 (1) syncObject 0xf435d2b8
  Thread 0xb2e78ba8 (-755586128) sleep=1, grant=0, locks=1, who 0, parent=(nil)
    Pending Table::validateAndInsert state 0 (1) syncObject 0xf435d2b8
  Thread 0xf40184a0 (-755385424) sleep=1, grant=0, locks=1, who 0, parent=(nil)
    Pending Table::validateAndInsert state 0 (1) syncObject 0xf435d2b8
  Thread 0xb2e78ef0 (-755786832) sleep=1, grant=0, locks=1, who 0, parent=(nil)
    Pending Table::validateAndInsert state 0 (1) syncObject 0xf435d2b8
Stalled synchronization objects:
  SyncObject f435d2b8: state 1, monitor 0, waiters 4
    Waiting thread b2e78ba8 (-755586128), type 1; Table::validateAndInsert
    Waiting thread f40184a0 (-755385424), type 1; Table::validateAndInsert
    Waiting thread b2e78ef0 (-755786832), type 1; Table::validateAndInsert
    Waiting thread f401c608 (-143410256), type 1; Table::validateAndInsert

Yes, you are right. 6.0.5, to be released shortly, uses -g for the optimized binary.

Thank you for a reasonable feature request.

This bug shows the same increase in the size of the record cache as Bug#34893.  That is due to the inability of the Falcon scavenger to prune old invisible records from the record cache until the scavenger threshold is reached.  I am working on that now.

This bug has the additional complaint that the performance of the test gets worse over time.  This may be due to the proliferation of unscavenged and un-garbage-collected stuff hanging around, especially in the system tables, since the file is created and dropped thousands of times.  So once the scavenger is pruning invisible records more efficiently, I will re-test the performance aspect.

Ignore previous comment.  It was for Bug#36700