だいたい`SHOW ENGINE INNODB STATUSの結果をエラーログファイルに定期的に吐き出してくれる'というイメージがある。
mysql> CREATE TABLE innodb_monitor ( hoge int );
$ tail -f error.log
=====================================
130306 10:09:30 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 20 seconds
-----------------
BACKGROUND THREAD
-----------------
..
----------------------------
END OF INNODB MONITOR OUTPUT
============================
そのまんまですね。
これなら正直、mysql -e "SHOW ENGINE INNODB STATUS\\G"を定期的に取れば良いかくらいなんですが、
InnoDB Monitorには他の種類もあって、
・InnoDBテーブルスペースモニター
mysql> CREATE TABLE innodb_tablespace_monitor ( hoge int );
$ tail -f error.log
================================================
130306 10:12:46 INNODB TABLESPACE MONITOR OUTPUT
================================================
FILE SPACE INFO: id 0
size 16000, free limit 15424, free extents 214
not full frag extents 9: used pages 256, full frag extents 2
first seg id not used 3546
SEGMENT id 1 space 0; page 2; res 928 used 778; full ext 11
fragm pages 32; free extents 0; not full extents 3: pages 42
SEGMENT id 2 space 0; page 2; res 1 used 1; full ext 0
fragm pages 1; free extents 0; not full extents 0: pages 0
SEGMENT id 3 space 0; page 2; res 1 used 1; full ext 0
fragm pages 1; free extents 0; not full extents 0: pages 0
..
SEGMENT id 3531 space 0; page 12105; res 1 used 1; full ext 0
fragm pages 1; free extents 0; not full extents 0: pages 0
NUMBER of file segments: 323
Validating tablespace
Validation ok
---------------------------------------
END OF INNODB TABLESPACE MONITOR OUTPUT
=======================================
Σ(゚д゚lll) すげえいっぱい!
ibdata1がどんな風に使われているのかをなんとなく見られそう。
(使い道は思い浮かばない)
・InnoDBテーブルモニター
mysql> CREATE TABLE innodb_table_monitor ( hoge int );
$ tail -f error.log
===========================================
130306 10:09:50 INNODB TABLE MONITOR OUTPUT
===========================================
..
--------------------------------------
TABLE: name tpcc/warehouse, id 27, flags 1, columns 12, indexes 1, appr.rows 0
COLUMNS: w_id: DATA_INT DATA_BINARY_TYPE DATA_NOT_NULL len 2; w_name: DATA_VARMYSQL len 30; w_street_1: DATA_VARMYSQL len 60
; w_street_2: DATA_VARMYSQL len 60; w_city: DATA_VARMYSQL len 60; w_state: DATA_MYSQL len 6; w_zip: DATA_MYSQL len 27; w_tax:
DATA_FIXBINARY DATA_BINARY_TYPE len 2; w_ytd: DATA_FIXBINARY DATA_BINARY_TYPE len 6; DB_ROW_ID: DATA_SYS prtype 256 len 6; DB_
TRX_ID: DATA_SYS prtype 257 len 6; DB_ROLL_PTR: DATA_SYS prtype 258 len 7;
INDEX: name PRIMARY, id 41, fields 1/11, uniq 1, type 3
root page 3, appr.key vals 0, leaf pages 1, size pages 1
FIELDS: w_id DB_TRX_ID DB_ROLL_PTR w_name w_street_1 w_street_2 w_city w_state w_zip w_tax w_ytd
FOREIGN KEY CONSTRAINT tpcc/fkey_district_1: tpcc/district ( d_w_id )
REFERENCES tpcc/warehouse ( w_id )
FOREIGN KEY CONSTRAINT tpcc/fkey_stock_1: tpcc/stock ( s_w_id )
REFERENCES tpcc/warehouse ( w_id )
-----------------------------------
END OF INNODB TABLE MONITOR OUTPUT
==================================
Σ(゚д゚lll) 何に使おうかイマイチ思いつかないけどすげえいっぱい。
トランザクションをかけてあれば、トランザクションIDに対応するロールバックポインターの情報も見られるのかしら。
・InnoDBロックモニター
mysql> CREATE TABLE innodb_lock_monitor ( hoge int );
$ tail -f error.log
=====================================
2013-03-06 10:46:14 7f22fa2b1700 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 20 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 221 srv_active, 0 srv_shutdown, 564473 srv_idle
srv_master_thread log flush and writes: 564694
..
----------------------------
END OF INNODB MONITOR OUTPUT
============================
( ゚д゚) ・・・
(つд⊂)ゴシゴシ
(;゚д゚) ・・・
(つд⊂)ゴシゴシゴシ
_, ._
(;゚ Д゚) …innodb_monitorと違わなくね?
と思ったら、ちゃんと違いました。
..
------------
TRANSACTIONS
------------
Trx id counter 13943
Purge done for trx's n:o < 13939 undo n:o < 0 state: running but idle
History list length 559
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 13941, ACTIVE 158 sec
2 lock struct(s), heap size 376, 13 row lock(s)
MySQL thread id 825, OS thread handle 0x7f22fcb12700, query id 3809 localhost root cleaning up
TABLE LOCK table `d1`.`t12` trx id 13941 lock mode IX
RECORD LOCKS space id 41 page no 3 n bits 80 index `GEN_CLUST_INDEX` of table `d1`.`t12` trx id 13941 lock_mode X
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;
Record lock, heap no 2 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 6; hex 00000000030c; asc ;;
1: len 6; hex 000000003655; asc 6U;;
2: len 7; hex ac000006310110; asc 1 ;;
3: len 3; hex 814000; asc @ ;;
Record lock, heap no 3 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 6; hex 00000000030d; asc ;;
1: len 6; hex 000000003655; asc 6U;;
2: len 7; hex ac00000631011e; asc 1 ;;
3: len 3; hex 814040; asc @@;;
Record lock, heap no 4 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 6; hex 00000000030e; asc ;;
1: len 6; hex 000000003655; asc 6U;;
2: len 7; hex ac00000631012c; asc 1 ,;;
3: len 3; hex 814080; asc @ ;;
..
TRANSACTIONSに出力されるレコードロックの情報がすごく多い。
LATEST DEADLOCKセクションに出てくるのと同じレベルで出力してる気がする。
これ頑張って解析したら色々捗りそうだけど、時間対効果はきっとすごく低いよなぁ。。
しかし出力が紛らわしい。innodb_monitorの出力と混じってるからログがごりごり流れるし。
ソースコード(storage/innobase/row/row0mysql.cc)読んでも、
} else if (STR_EQ(table_name, table_name_len,両方出力させてるっぽいことは判るんだけど、それが正しいのかどうかよく判らなかった。。
S_innodb_lock_monitor)) {
srv_print_innodb_monitor = TRUE;
srv_print_innodb_lock_monitor = TRUE;
os_event_set(lock_sys->timeout_event);
5.5.8までさかのぼってコンパイルしてこの動作で良いのか調べてみたり。
ところでマニュアルのいわく。
The InnoDB Lock Monitor is like the standard Monitor but also provides extensive lock information.http://dev.mysql.com/doc/refman/5.6/en/innodb-monitors.html
orz
ちなみにこれ、5.0の時代からある古い機能なんですね。
http://dev.mysql.com/doc/refman/5.0/en/innodb-monitors.html
innodb_monitor以外は知らなかった。
【2013/03/27 12:00】
ごめんなさい、これ、作ったinnodb*_monitorテーブルをドロップするまで、
数十秒ごとにエラーログにこの出力結果を吐き出し続けます。
止めるには
mysql> DROP TABLE <作ったテーブル>;
です。
すっかり書くの忘れてた。。
0 件のコメント :
コメントを投稿