摘要: 轉自：http://blogold.chinaunix.net/u3/102731/showart_2270571.html
http://book.51cto.com/art/200803/68118.htm
摘要：《深 入淺出MySQL——數據庫開發、優化與管理維護》從數據庫的基礎、開發、優化、管理4方面對MySQL進行了詳細的介紹，其中每一部分都獨立成篇，每一 篇又包括多個章節。本書...
閱讀全文
posted @
2011-04-26 11:29 哈哈的日子 閱讀(598) |
評論 (0) |
編輯 收藏
轉自：http://5iwww.blog.51cto.com/856039/340985
shell> mysqlbinlog log-file
使用mysqldumpslow命令獲得日志中顯示的查詢摘要來處理慢查詢日志， 例如：
[zzx@bj37 data]$ mysqldumpslow bj37-slow.log
一.1 獲 取鎖等待情況
可以通過檢查 table_locks_waited和table_locks_immediate狀態變量來分析系統上的表鎖定爭奪：
mysql> show status like 'Table%';
+----------------------------+----------+
| Variable_name | Value |
+----------------------------+----------+
| Table_locks_immediate | 105 |
| Table_locks_waited | 3 |
+----------------------------+----------+
2 rows in set (0.00 sec)
可以通過檢查 Innodb_row_lock狀態變量來分析系統上的行鎖的爭奪情況：
mysql> show status like 'innodb_row_lock%';
+----------------------------------------+----------+
| Variable_name | Value |
+----------------------------------------+----------+
| Innodb_row_lock_current_waits | 0 |
| Innodb_row_lock_time | 2001 |
| Innodb_row_lock_time_avg | 667 |
| Innodb_row_lock_time_max | 845 |
| Innodb_row_lock_waits | 3 |
+----------------------------------------+----------+
5 rows in set (0.00 sec)
另外，針對Innodb類型的表，如果 需要察看當前的鎖等待情況，可以設置InnoDB Monitors，然后通過Show innodb status察看，設置的方式是：
CREATE TABLE innodb_monitor(a INT) ENGINE=INNODB;
監視器可以通過發出下列語句來被停止：
DROP TABLE innodb_monitor;
設置監視器后，在show innodb status的顯示內容中，會有詳細的當前鎖等待的信息，包括表名、鎖類型、鎖定記錄的情況等等，便于進行進一步的分析和問題的確定。打開監視器以后，默 認情況下每15秒會向日志中記錄監控的內容，如果長時間打開會導致.err文件變得非常的巨大，所以我們在確認問題原因之后，要記得刪除監控表以關閉監視 器。或者通過使用--console選項來啟動服務器以關閉寫日志文件。
如果是root帳號，你能看到所有用戶的當前連接。如果是其它普通帳號，只能看到自己占用的連接。
show processlist;只 列出前100條，如果想全列出請使用show full processlist;
mysql> show processlist;（非常管用哦）
posted @
2011-04-26 10:17 哈哈的日子 閱讀(2865) |
評論 (0) |
編輯 收藏
轉自51cto：http://g.51cto.com/mike/67136
動innodb_monitor的方法
在使用Innodb做為存儲引擎的數據庫系統中，可以使用innodb_monitor 來監控數據庫的性能，啟動innodb_monitor的方法為 Create table innodb_monitor (i int) engine=innodb 通過建立這個表就啟動了innodb_monitor，監控的結果并不會記錄到這個表中，而是記錄到了mysql的err日志中，如果我們想監控更我的關于innodb的鎖信息還可更進一步的建立表create table innodb_lock_monitor (i int) engine=innodb 這樣在日志中會加入更多的鎖信息，如果要關閉監控只要簡單的刪除這兩個表就可以了.Drop table innodb_monitor; drop table innodb_lock_monitor;
用InnoDB monitor 可以監控死鎖的情況等用InnoDB monitor 可以監控死鎖的情況等
InnoDB引擎提供了一個monitor，可以通過monitor一窺其內部的一些統計信息，也可以說是了解InnoDB引擎的一個很好的窗口。
我們最熟悉的，應當就是show innodb status命令，可以直接在客戶端輸出很多的信息。其實InnoDB monitor一共有四種模式，show innodb status只是其一種模式的直接展現，并且只能交互式開啟，無法自動循環捕獲信息。另外還有一種適合四種模式的開啟方式，則是通過創建一張特殊的innodb表來開啟，開啟后會按照固定的時間間隔循環，輸出信息到log-error參數指定的錯誤日志文件中，通過drop對應的表，可以停止monitor。
四種monitor分別是:
- innodb_monitor：create table innodb_monitor(x int) engine=innodb;
- innodb_lock_monitor：create table innodb_lock_monitor(x int) engine=innodb;
- innodb_table_monitor：create table innodb_table_monitor(x int) engine=innodb;
- innodb_tablespace_monitor：create table innodb_tablespace_monitor(x int) engine=innodb;
根據我在5.1.36版本中實際觀察到的結果，innodb_monitor/innodb_lock_monitor開啟后的執行周期是
16s（
參考手冊上說是15s），而innodb_table_monitor/innodb_tablespace_monitor的執行周期是
64s。開啟monitor后因為是持續周期性的運行的，在不需要的時候一定要記得drop相關表來停止monitor。如果在開啟monitor的中間服務器有重啟，monitor不會自動重啟，并且在下次啟動monitor之前，必須先執行停止操作。
其中innodb_monitor/innodb_lock_monitor兩種監視器的輸出結果基本類似，后者會有更多關于鎖的信息，而前一個實際上就是show innodb status。innodb_table_monitor則會將系統中所有innodb的表的一些結構和內部信息輸出，而innodb_tablespace_monitor則輸出的是tablespace的信息，注意該monitor輸出的只是共享表空間的信息，如果使用innodb_file_per_table為每個表使用獨立的表空間，則這些表空間的信息是不會包含在輸出中的。
以下是一些簡單的示例：
innodb_monitor/innodb_lock_monitor：
=====================================
090805 22:24:48 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 19 seconds
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 312921, signal count 308229
Mutex spin waits 0, rounds 18209349, OS waits 111906
RW-shared spins 287775, OS waits 142204; RW-excl spins 175036, OS waits 19318
------------
TRANSACTIONS
------------
Trx id counter 0 121675664
Purge done for trx's n:o < 0 121675662 undo n:o < 0 0
History list length 10
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 0 121462143, not started, process no 8452, OS thread id 1160767840
mysql tables in use 1, locked 1
MySQL thread id 8056144, query id 78206864 localhost root
---TRANSACTION 0 137229, not started, process no 8452, OS thread id 1158199648
MySQL thread id 50, query id 377 Has read all relay log; waiting for the slave I/O thread to update it
--------
FILE I/O
--------
I/O thread 0 state: waiting for i/o request (insert buffer thread)
I/O thread 1 state: waiting for i/o request (log thread)
I/O thread 2 state: waiting for i/o request (read thread)
I/O thread 3 state: waiting for i/o request (write thread)
Pending normal aio reads: 0, aio writes: 0,
ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
Pending flushes (fsync) log: 0; buffer pool: 0
34 OS file reads, 80820900 OS file writes, 1263117 OS fsyncs
0.00 reads/s, 0 avg bytes/read, 1.16 writes/s, 0.63 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 0, seg size 2,
0 inserts, 0 merged recs, 0 merges
Hash table size 8850487, node heap has 233 buffer(s)
0.11 hash searches/s, 0.42 non-hash searches/s
---
LOG
---
Log sequence number 4 3697502095
Log flushed up to 4 3697502095
Last checkpoint at 4 3697502095
0 pending log writes, 0 pending chkp writes
79595438 log i/o's done, 0.47 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 4851752298; in additional pool allocated 13195520
Dictionary memory allocated 145784
Buffer pool size 262144
Free buffers 193334
Database pages 68577
Modified db pages 0
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages read 70, created 120513, written 2829967
0.00 reads/s, 0.21 creates/s, 0.84 writes/s
Buffer pool hit rate 1000 / 1000
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
1 read views open inside InnoDB
Main thread process no. 8452, id 1157658976, state: waiting for server activity
Number of rows inserted 12233742, updated 57497659, deleted 1, read 69720050
0.05 inserts/s, 0.05 updates/s, 0.00 deletes/s, 0.05 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT
============================
innodb_table_monitor：
===========================================
090805 22:26:56 INNODB TABLE MONITOR OUTPUT
===========================================
--------------------------------------
TABLE: name SYS_FOREIGN, id 0 11, columns 7, indexes 3, appr.rows 0
COLUMNS: ID: DATA_VARCHAR prtype 1835012 len 0; FOR_NAME: DATA_VARCHAR prtype 1835012 len 0;
REF_NAME: DATA_VARCHAR prtype 1835012 len 0; N_COLS: DATA_INT len 4;
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 ID_IND, id 0 11, fields 1/6, uniq 1, type 3
root page 46, appr.key vals 0, leaf pages 1, size pages 1
FIELDS: ID DB_TRX_ID DB_ROLL_PTR FOR_NAME REF_NAME N_COLS
INDEX: name FOR_IND, id 0 12, fields 1/2, uniq 2, type 0
root page 47, appr.key vals 0, leaf pages 1, size pages 1
FIELDS: FOR_NAME ID
INDEX: name REF_IND, id 0 13, fields 1/2, uniq 2, type 0
root page 48, appr.key vals 0, leaf pages 1, size pages 1
FIELDS: REF_NAME ID
...省略若干輸出
--------------------------------------
TABLE: name test/test, id 0 81, columns 4, indexes 1, appr.rows 3
COLUMNS: i: DATA_INT DATA_BINARY_TYPE len 4; 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 GEN_CLUST_INDEX, id 0 23, fields 0/4, uniq 1, type 1
root page 3, appr.key vals 3, leaf pages 1, size pages 1
FIELDS: DB_ROW_ID DB_TRX_ID DB_ROLL_PTR i
-----------------------------------
END OF INNODB TABLE MONITOR OUTPUT
==================================
innodb_tablespace_monitor：
================================================
090805 22:28:16 INNODB TABLESPACE MONITOR OUTPUT
================================================
FILE SPACE INFO: id 0
size 65536, free limit 6208, free extents 89
not full frag extents 6: used pages 69, full frag extents 0
first seg id not used 0 1067667
SEGMENT id 0 1067666 space 0; page 903; res 1 used 1; full ext 0
fragm pages 1; free extents 0; not full extents 0: pages 0
...省略若干輸出
SEGMENT id 0 144216 space 0; page 1307; res 1 used 1; full ext 0
fragm pages 1; free extents 0; not full extents 0: pages 0
NUMBER of file segments: 37
Validating tablespace
Validation ok
---------------------------------------
END OF INNODB TABLESPACE MONITOR OUTPUT
=======================================
posted @
2011-04-26 09:53 哈哈的日子 閱讀(302) |
評論 (0) |
編輯 收藏轉自MySQL 中文網：http://imysql.cn/2008_05_22_walk_through_show_innodb_status
感謝兩個作者，呵呵
原文作者： Peter Zaitsev
原文來源： http://www.mysqlperformanceblog.com/2006/07/17/show-innodb-status-walk-through/
譯者：葉金榮（Email:
），轉載請注明譯者和出處，并且不能用于商業用途，違者必究。
很多人讓我來闡述一下 SHOW INNODB STATUS 的輸出信息, 了解 SHOW INNODB STATUS 都輸出了些什么信息，并且我們能從這些信息中獲取什么資訊，得以提高 MySQL 性能。
首先，讓我們來了解一下 SHOW INNODB STATUS 輸出的基礎，它打印了很多關于 InnoDB 內部性能相關的計數器、統計、事務處理信息等。在 MySQL 5 中，InnoDB 的性能統計結果也在 SHOW STATUS 結果中顯示了。大部分和 SHOW INNODB STATUS 的其他信息相同，在舊版本中還沒有這個功能。
SHOW INNODB STATUS 中的很多統計值都是每秒更新一次的，如果你打算利用這些統計值的話，那么最好統計一段時間內的結果。InnoDB 首先輸出以下信息：
1.=====================================
2.060717 3:07:56 INNODB MONITOR OUTPUT
3.=====================================
4.Per second averages calculated from the last 44 seconds
首先要確認這是至少統計了 20-30 秒的樣本數據。如果平均統計間隔是0或1秒，那么結果就沒什么意義了。
說實在的我不喜歡InnoDB提供的平均值，因為很難取得合理的平均間隔統計值，如果你是寫腳本來取得 SHOW INNODB STATUS 結果的話，那么最好取得全局的統計結果，然后取得平均值。當然了，直接查看輸出的結果信息也是很有用的。
下一部分顯示了信號(Semaphores)相關信息：
1.----------
2.SEMAPHORES
3.----------
4.OS WAIT ARRAY INFO: reservation count 13569, signal count 11421
5.--Thread 1152170336 has waited at ./../include/buf0buf.ic line 630 for 0.00 seconds the semaphore:
6.Mutex at 0x2a957858b8 created file buf0buf.c line 517, lock var 0
7.waiters flag 0
8.wait is ending
9.--Thread 1147709792 has waited at ./../include/buf0buf.ic line 630 for 0.00 seconds the semaphore:
10.Mutex at 0x2a957858b8 created file buf0buf.c line 517, lock var 0
11.waiters flag 0
12.wait is ending
13.Mutex spin waits 5672442, rounds 3899888, OS waits 4719
14.RW-shared spins 5920, OS waits 2918; RW-excl spins 3463, OS waits 3163
這段可以分成2個部分。一部分是當前的等待，這部分只是包含了在高并發環境下的全部記錄，因此 InnoDB 會頻繁回退到系統等待。如果等待是通過自旋鎖來解決的話，那么這些信息就就不會顯示了。
通過這部分信息，你就會知道系統負載的熱點在哪了。不過這需要了解一下源碼相關的知識 - 從上面的信息中就可以看出來是哪個源碼文件中的哪行(不同的版本結果可能不同)，只是從這里卻看不出來任何信息。盡管如此，還是可以從文件名中猜到一些東西 - 比如本例中，文件名 "buf0buf.ic" 預示著和一些緩沖池爭奪有關系。如果想了解更多，就去看源碼吧。
還有一些關于等待的更多細節。"lock var" 表示當前的 mutex 對象的值(被鎖住 = 1 / 釋放 = 0) 值，"waiters flag" 表示當前的等待個數。另外，本例中還可以看到等待狀態信息 "wait is ending"，這表示 mutex 已經釋放，但是系統調度線程還正在處理。
第二塊是事件統計 - "reservation count" 和 "signal count" 顯示了 innodb 使用內部同步陣列的活躍程度 - 時間片(slot)分配以及線程信號使用同步陣列的頻繁程度。這些統計信息可以用于表示 innodb 回退到系統等待的頻率。還有關于系統等待的直接相關信息，可以看到"OS Waits"的互斥信號燈(mutexes)，以及讀寫鎖。這些信息中顯示了互斥鎖和共享鎖。系統等待和 "保留(reservation)" 不完全一樣，在回退到用 sync_array 的復雜等待模式前，innodb 會嘗試 "輸出(yield)" 到系統，希望下一次調度時間對象里命名線程已經釋放了。系統等待相對較慢，如果每秒發生了上萬次系統等待，則可能會有問題。另一個觀察方法是查看系統狀態中的上下文(context)交換頻率。
另一塊重要的信息是 "spin waits" 和 "spin rounds" 的數量。相較于系統等待，自旋鎖是低成本的等待；不過它是一個活躍的等待，會浪費一些cpu資源。因此如果看到大量的自旋等待和自旋輪轉，則很顯然它浪費了很多cpu資源。浪費cpu時間和無謂的上下文切換之間可以用 innodb_sync_spin_loops 來平衡。
接下來的這段顯示死鎖狀況:
1.------------------------
2.LATEST DETECTED DEADLOCK
3.------------------------
4.060717 4:16:48
5.*** (1) TRANSACTION:
6.TRANSACTION 0 42313619, ACTIVE 49 sec, process no 10099, OS thread id 3771312 starting index read
7.mysql tables in use 1, locked 1
8.LOCK WAIT 3 lock struct(s), heap size 320
9.MySQL thread id 30898, query id 100626 localhost root Updating
10.update iz set pad='a' where i=2
11.*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
12.RECORD LOCKS space id 0 page no 16403 n bits 72 index `PRIMARY` of table `test/iz` trx id 0 42313619 lock_mode X locks rec but not gap waiting
13.Record lock, heap no 5 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
14. 0: len 4; hex 80000002; asc ;; 1: len 6; hex 00000285a78f; asc ;; 2: len 7; hex 00000040150110; asc @ ;; 3: len 10; hex 61202020202020202020; asc a ;;
15.
16.*** (2) TRANSACTION:
17.TRANSACTION 0 42313620, ACTIVE 24 sec, process no 10099, OS thread id 4078512 starting index read, thread declared inside InnoDB 500
18.mysql tables in use 1, locked 1
19.3 lock struct(s), heap size 320
20.MySQL thread id 30899, query id 100627 localhost root Updating
21.update iz set pad='a' where i=1
22.*** (2) HOLDS THE LOCK(S):
23.RECORD LOCKS space id 0 page no 16403 n bits 72 index `PRIMARY` of table `test/iz` trx id 0 42313620 lock_mode X locks rec but not gap
24.Record lock, heap no 5 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
25. 0: len 4; hex 80000002; asc ;; 1: len 6; hex 00000285a78f; asc ;; 2: len 7; hex 00000040150110; asc @ ;; 3: len 10; hex 61202020202020202020; asc a ;;
26.
27.*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
28.RECORD LOCKS space id 0 page no 16403 n bits 72 index `PRIMARY` of table `test/iz` trx id 0 42313620 lock_mode X locks rec but not gap waiting
29.Record lock, heap no 4 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
30. 0: len 4; hex 80000001; asc ;; 1: len 6; hex 00000285a78e; asc ;; 2: len 7; hex 000000003411d9; asc 4 ;; 3: len 10; hex 61202020202020202020; asc a ;;
31.
32.*** WE ROLL BACK TRANSACTION (2)
這里顯示了 Innodb 最后檢測到事務引發的死鎖，包括發生死鎖時的狀態，加了什么鎖，在等待什么鎖釋放，以及 Innodb 決定哪個事務會被回滾。注意，innodb只顯示了事務持有鎖的相關簡單信息。并且只顯示了每個事務最后執行的語句，發生死鎖的記錄就是由于這些語句引起的。查看復雜的死鎖信息還需要查看日志文件，才能找到真正引發沖突的語句。大部分情況下，SHOW INNODB STATUS 顯示的信息基本足夠了。
下面是關于外鍵約束引發的死鎖信息：
1.------------------------
2.LATEST FOREIGN KEY ERROR
3.------------------------
4.060717 4:29:00 Transaction:
5.TRANSACTION 0 336342767, ACTIVE 0 sec, process no 3946, OS thread id 1151088992 inserting, thread declared inside InnoDB 500
6.mysql tables in use 1, locked 1
7.3 lock struct(s), heap size 368, undo log entries 1
8.MySQL thread id 9697561, query id 188161264 localhost root update
9.insert into child values(2,2)
10.Foreign key constraint fails for table `test/child`:
11.,
12. CONSTRAINT `child_ibfk_1` FOREIGN KEY (`parent_id`) REFERENCES `parent` (`id`) ON DELETE CASCADE
13.Trying to add in child table, in index `par_ind` tuple:
14.DATA TUPLE: 2 fields;
15. 0: len 4; hex 80000002; asc ;; 1: len 6; hex 000000000401; asc ;;
16.
17.But in parent table `test/parent`, in index `PRIMARY`,
18.the closest match we can find is record:
19.PHYSICAL RECORD: n_fields 3; 1-byte offs TRUE; info bits 0
20. 0: len 4; hex 80000001; asc ;; 1: len 6; hex 0000140c2d8f; asc - ;; 2: len 7; hex 80009c40050084; asc @ ;;
Innodb會顯示引發錯誤的語句。外鍵約束定義失敗，以及定義關系最密切的父表。有很多嵌接信息都是用16進制表示，不過對于問題診斷并不是太重要，它們主要用于給 Innodb 的開發者來查看或者用于調試目的。
接下來是顯示 Innodb 當前活躍的事務：
1.------------
2.TRANSACTIONS
3.------------
4.Trx id counter 0 80157601
5.Purge done for trx's n:o <0 80154573 undo n:o <0 0
6.History list length 6
7.Total number of lock structs in row lock hash table 0
8.LIST OF TRANSACTIONS FOR EACH SESSION:
9.---TRANSACTION 0 0, not started, process no 3396, OS thread id 1152440672
10.MySQL thread id 8080, query id 728900 localhost root
11.show innodb status
12.---TRANSACTION 0 80157600, ACTIVE 4 sec, process no 3396, OS thread id 1148250464, thread declared inside InnoDB 442
13.mysql tables in use 1, locked 0
14.MySQL thread id 8079, query id 728899 localhost root Sending data
15.select sql_calc_found_rows * from b limit 5
16.Trx read view will not see trx with id>= 0 80157601, sees <0 80157597
17.---TRANSACTION 0 80157599, ACTIVE 5 sec, process no 3396, OS thread id 1150142816 fetching rows, thread declared inside InnoDB 166
18.mysql tables in use 1, locked 0
19.MySQL thread id 8078, query id 728898 localhost root Sending data
20.select sql_calc_found_rows * from b limit 5
21.Trx read view will not see trx with id>= 0 80157600, sees <0 80157596
22.---TRANSACTION 0 80157598, ACTIVE 7 sec, process no 3396, OS thread id 1147980128 fetching rows, thread declared inside InnoDB 114
23.mysql tables in use 1, locked 0
24.MySQL thread id 8077, query id 728897 localhost root Sending data
25.select sql_calc_found_rows * from b limit 5
26.Trx read view will not see trx with id>= 0 80157599, sees <0 80157595
27.---TRANSACTION 0 80157597, ACTIVE 7 sec, process no 3396, OS thread id 1152305504 fetching rows, thread declared inside InnoDB 400
28.mysql tables in use 1, locked 0
29.MySQL thread id 8076, query id 728896 localhost root Sending data
30.select sql_calc_found_rows * from b limit 5
31.Trx read view will not see trx with id>= 0 80157598, sees <0 80157594
如果當前連接不是很多，則會顯示全部事務列表；如果有大量連接，則 Innodb 只會顯示他們的數量，減少輸出的列表信息，使得輸出結果不會太多。
事務ID是當前事務的標識，事務的id每次都會增加。Purge done for trx's n:o 是指凈化(purge)線程已經完成的事務數。Innodb僅清除那些被當前事務認為不再需要的舊版本數據。那些未提交的舊事務可能會阻塞凈化線程并且消耗資源。通過查看2次清除事務數之差，就可以知道是否發生了這種情況。少數情況下，凈化線程可能難以跟上更新的速度，2次查看值之差可能會越來越大；那么，innodb_max_purge_lag 就派得上用場了。 "undo n:o" 顯示了凈化線程當前正在處理的回滾日志號，如果當前不處于活躍狀態，則它的值是 0。
History list length 6 是指在回滾空間中的未清除事務數。隨著事務的提交，它的值會增加；隨著清除線程的運行，它的值會減小。
Total number of lock structs in row lock hash table 是指事務分配過的行鎖結構總數。它和曾經被鎖住過的行總數不一定相等，通常是一個鎖結構對應多行記錄。
MySQL中，每個連接如果沒有活動的事務，則它的狀態是 not started，如果有活動的事務，則是 ACTIVE。注意，盡管事務是活動的，但是其連接的狀態卻可能是 "睡眠(sleep)" - 如果是在一個有多條語句的事務里的話。Innodb 會同時顯示系統的線程號以及進程號，這有助于利用gdb來調試或者其他類似用途。另外，事務的狀態也會根據當前實際狀態來顯示，例如 "讀取記錄(fetching rows)"，em>"更新(updating)"等等。"Thread declared inside InnoDB 400" 的意思是 Innodb 內核正在運行該線程，并且還需要400個票。Innodb 會根據 innodb_thread_concurrency 的值來限制同時并發的線程數不超過它。如果線程當前不在 Innodb 的內核中運行，則它的狀態可能是 "waiting in InnoDB queue" 或 "sleeping before joining InnoDB queue"。后面這個狀態有點意思 - Innodb 為了避免有太多的線程同時搶著要進入運行隊列，那么就會嘗試讓這些線程進入等待狀態(如果沒有足夠的空閑插槽(slot)的話)。這就可能會導致 Innodb 內核中當前活躍的線程數可能比innodb_thread_concurrency 的值還小。某種負載環境下，這可能有助于減小線程進入隊列的時間。可以通過調整 innodb_thread_sleep_delay 來實現，它的單位是微妙。
mysql tables in use 1, locked 0 是指事務中已經用過的數據表個數(已經訪問過了的)，以及被鎖的個數。Innodb 一般情況不會鎖表，因此鎖表數一般是0，除非是ALTER TABLE 或者其他類似 LOCK TABLES 的語句。
除了Innodb相關的特定信息外，一些基本信息可以通過 來查看，例如正在執行什么語句，查詢ID號，查詢狀態等。
下面這部分顯示的是跟IO相關的具體信息：
1.--------
2.FILE I/O
3.--------
4.I/O thread 0 state: waiting for i/o request (insert buffer thread)
5.I/O thread 1 state: waiting for i/o request (log thread)
6.I/O thread 2 state: waiting for i/o request (read thread)
7.I/O thread 3 state: waiting for i/o request (write thread)
8.Pending normal aio reads: 0, aio writes: 0,
9. ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
10.Pending flushes (fsync) log: 0; buffer pool: 0
11.17909940 OS file reads, 22088963 OS file writes, 1743764 OS fsyncs
12.0.20 reads/s, 16384 avg bytes/read, 5.00 writes/s, 0.80 fsyncs/s
本部分顯示了IO助手線程狀態 - 插入緩沖線程，日志線程，讀、寫線程。它們分別對應插入緩沖合并，異步日志刷新，預讀以及刷新臟數據。源自查詢的正常讀取是由正在運行的查詢執行的。在Unix/Linux平臺下，總能看見4個線程，在Windows上可以通過 innodb_file_io_threads 來調整。每個線程準備好之后都能看到其狀態：waiting for i/o request 或者正在執行特定的操作。
每個線程都會顯示正在進行的操作數量 - 同時正要執行或者正在執行的操作數量。另外，正在執行的 fsync 操作數量也會顯示出來。有寫數據時，Innodb需要確保數據最終被寫到磁盤上，只是把它們放在系統緩存里是不夠的。通常是調用 fsync() 來完成的。如果它的值一直很高，那意味這Innodb可能是處于IO負載較高狀態。注意，由線程執行請求引發的IO請求是不計算在內的，因此盡管系統的IO負載較高，但是它們的值卻可能為 0。
接下來顯示的是IO操作的平均統計值，它們對于圖形顯示或者監控很有用。
"16384 avg bytes/read" 是讀請求的平均值。隨機IO的話，每個頁的大小是16K，全表掃描或索引掃描時的預讀會導致這個值明顯的增加。因此，它體現了預讀的效率。
1.-------------------------------------
2.INSERT BUFFER AND ADAPTIVE HASH INDEX
3.-------------------------------------
4.Ibuf for space 0: size 1, free list len 887, seg size 889, is not empty
5.Ibuf for space 0: size 1, free list len 887, seg size 889,
6.2431891 inserts, 2672643 merged recs, 1059730 merges
7.Hash table size 8850487, used cells 2381348, node heap has 4091 buffer(s)
8.2208.17 hash searches/s, 175.05 non-hash searches/s
本部分顯示了插入緩沖以及自適應哈希索引的狀態。第一行顯示了插入緩沖的狀態 - 段的大小以及空閑列表，以及緩沖中有多少記錄。接下來顯示了緩沖中已經完成了多少次插入，有多少記錄已經合并，有多少次合并已經完成。合并次數除以插入次數得到的比率可以反映出插入緩沖的效率如何。
Innodb采用哈希索引建立內存頁索引形成自適應哈希索引而不是采 B-tree 索引，得以加速行記錄到內存頁的檢索。這里顯示了哈希表的大小，以及自適應哈希索引使用了多少單元和緩沖。可以通過計算利用哈希索引檢索的次數以及沒利用它檢索的次數來了解哈希索引的效率。
當前對自適應哈希索引基本沒有什么辦法可以調整它，主要還是用于查看。
1.---
2.LOG
3.---
4.Log sequence number 84 3000620880
5.Log flushed up to 84 3000611265
6.Last checkpoint at 84 2939889199
7.0 pending log writes, 0 pending chkp writes
8.14073669 log i/o's done, 10.90 log i/o's/second
接下來顯示的是Innodb的日志子系統相關信息。可以看到當前的日志序列號 - 相當于Innodb自從表空間開始創建直到現在已經寫入日志文件的總字節數。還可以看到日志已經刷新到哪個點，同樣也可以根據最后檢查點計算出還有多少日志沒有刷新到文件中去。Innodb采用模糊檢查點，因此這行顯示的是已經從緩沖池中刷新到文件的日志序列號。由于更高的日志序列號可能不會被立刻刷新到日志文件中去，因此日志序列號不能被覆蓋掉。通過監控刷新到哪個日志的日志序列，可以判定innodb_log_buffer_size 的設置是否合理，如果看到超過 30% 的日志還沒有刷新到日志文件中，則需要考慮增加它的值了。
另外，還能看到日志寫入以及檢查點的數目。根據日志 I/O 操作的數目可以區分開表空間相關的IO請求和日志IO請求數量，進而可以確定到底需要幾個日志文件。注意，innodb_flush_log_at_trx_commit 的值可以影響到日志寫操作的代價高或低。如果 innodb_flush_logs_at_trx_commit=2，則日志是寫到系統緩存，然后再順序寫到日志文件中，因此相對會快很多。
1.----------------------
2.BUFFER POOL AND MEMORY
3.----------------------
4.Total memory allocated 4648979546; in additional pool allocated 16773888
5.Buffer pool size 262144
6.Free buffers 0
7.Database pages 258053
8.Modified db pages 37491
9.Pending reads 0
10.Pending writes: LRU 0, flush list 0, single page 0
11.Pages read 57973114, created 251137, written 10761167
12.9.79 reads/s, 0.31 creates/s, 6.00 writes/s
13.Buffer pool hit rate 999 / 1000
這部分顯示了緩沖池和內存的利用率相關信息。可以看到Innodb分配的所有內存(有些時候可能比你設置的還要多點)，以及額外的內存池分配情況(可以檢查它的大小是否正好)，緩沖池總共有多少個內存頁，有多少空閑內存頁，數據庫分配了多少個內存頁以及有多少個臟內存頁。從這些信息中，就可以判斷內存緩沖池是否設定合理，如果總是有大量空閑內存頁，則不需要設置那么多內存，可以適當減小一點。如果空閑內存頁為 0，這種情況下數據庫內存頁就不一定會和緩沖池的總數一致，因為緩沖池還需要保存鎖信息，自適應哈希索引以及其他系統結構等信息。
等待中的讀寫是指內存緩沖池級別的請求。Innodb可能會把多個文件級別的請求合并到一個上，因此各不相同。我們還可以看到Innodb提交的各種不同類型的IO，LRU內存頁中需要刷新的頁 - 臟內存頁，它們不會被長時間存取；刷新列表 -
檢查點進程處理完之后需要刷新的舊內存頁；獨立內存頁 - 獨立的寫內存頁。
我們還可以看到內存頁總共讀寫了多少次。已經創建的內存頁是當前一個內存頁中的內容沒有讀取到內存緩沖池中時，專門為新數據創建的空內存頁。
最后我們可以看到緩沖池的命中率，它預示著緩沖池的效率。1000/1000 相當于 100% 的命中率。不過這樣也很難說明緩沖池的命中率就足夠高了，這要需要根據不同的負載環境而定。通常情況下，950/1000 就夠了，有些時候在IO負載較高的環境下，命中率可能為 995/1000。
1.--------------
2.ROW OPERATIONS
3.--------------
4.0 queries inside InnoDB, 0 queries in queue
5.1 read views open inside InnoDB
6.Main thread process no. 10099, id 88021936, state: waiting for server activity
7.Number of rows inserted 143, updated 3000041, deleted 0, read 24865563
8.0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
最后一部分，顯示了數據行操作以及一些系統信息相關情況。
一開始顯示了Innodb線程隊列狀態 - 有多少線程處于等待或活躍的。Innodb內部打開了多少讀視圖 -
這是在事務開始后，但是當前還沒有活躍語句的情況，Innodb主線程的狀態控制了系統操作調度的數量 - 刷新臟內存頁、檢查點、凈化線程、刷新日志、合并插入緩沖等。 "state" 的值則表示了主線程當前的狀態。
接下來可以看到自從系統啟動以來，所有的數據行操作數量及其平均值。它們可以很方便地用于監控以及畫出系統狀態圖，數據行操作次數可以很好的衡量Innodb的負載。不是所有的數據行操作帶來的負載都是一樣的，存取10字節的行比10Mb的行相比會小了很多，不過相對于查詢的總次數來說這個信息可是有用的多了，差別也很大。
還有一點需要注意的是，SHOW INNODB STATUS 不是一成不變的，有些時間點上可能會不相符。SHOW INNODB STATUS結果中，不同時間可能會顯示不同結果，因此有些時候可能會看到沖突的信息。這是由于設計時需要由全局鎖提供一致性信息，導致了大量的開銷。
posted @
2011-04-26 09:51 哈哈的日子 閱讀(544) |
評論 (0) |
編輯 收藏
很長一段時間使用 mac os x 目前是 snow leopard，最讓我惱火的就是他的快捷鍵。
我是大部分操作靠鍵盤的人，但切換到 mac 后，曾經和同事說，基本上是“武功全廢”。
直到今天，給老婆買了新 mbp 后，才發現，原來。。。。是我土了！！！
原來，在設置－>鍵盤－>鍵盤快捷鍵，里面，有一項叫“全鍵盤控制”，可以切換，快捷鍵是 control + F7。
生活，原來可以更美一點兒的，真的！
posted @
2011-04-21 22:45 哈哈的日子 閱讀(164) |
評論 (0) |
編輯 收藏
我的 m2eclipse 下載 source 功能老是不好用，只好用命令行了。
mvn eclipse:eclipse -DdownloadSources=true
or
mvn eclipse:eclipse -DdownloadJavadocs=true
posted @
2011-04-16 17:23 哈哈的日子 閱讀(634) |
評論 (0) |
編輯 收藏
sudo lsof -i -P | grep 2144 | awk '$2 != 2144 {print $2}' | xargs ps -fp | awk 'NR > 1 {print $3}' | xargs kill -15
posted @
2011-03-13 17:45 哈哈的日子 閱讀(337) |
評論 (0) |
編輯 收藏
目標：
copy 國際化資源文件，*.properties 至 *_en_US.properties，但有一些不是國際化資源的配置文件被誤 copy 了，國際化資源的判斷標準是同時還有一個 *_zh_CN.properties 文件
<target>
<pathconvert property="x" pathsep="," targetos="unix">
<path>
<fileset dir="src/main/resources" includes="**/*_zh_CN.properties" />
</path>
<mapper type="regexp" from=".*?src/main/resources/(.*?)_zh_CN.properties$" to="\1.properties" />
</pathconvert>
<copy todir="${project.build.outputDirectory}">
<fileset dir="src/main/resources" includes="${x}" />
<mapper type="regexp" from="^(.*?).properties$" to="\1_en_US.properties" />
</copy>
</target>
posted @
2011-03-10 19:31 哈哈的日子 閱讀(269) |
評論 (0) |
編輯 收藏
現象：
eclipse subversive plugin 快捷鍵無效
原因：
據說是 eclipse 高版本的 api 和 subversive 不太匹配，不確定。
解決：
Window -> Customize Perspective -> Command Groups Availability -> 左側 Available command groups -> 選擇 SVN
posted @
2011-03-09 10:53 哈哈的日子 閱讀(1273) |
評論 (0) |
編輯 收藏
有一位居士，在江邊散步，看到一個船夫將沙灘上的渡舟推向江里，準備載客渡江。此時剛好有一位禪師路過，這個居士于是向前作禮請示道：“請問禪師，剛才船夫將舟推入江時，將江灘上的螃蟹、蝦、螺等壓死不少，請問這是乘客的罪過？還是船夫的罪過？”
禪師沒有考慮，就回答道：“既不是乘客的罪過，也不是船夫的罪過！”
居士非常不解，懷疑地問道：“兩者都沒有罪過，那么是誰的罪過？”
禪師兩眼圓睜，大聲道：“是你的罪過！”
posted @
2011-02-20 22:39 哈哈的日子 閱讀(129) |
評論 (0) |
編輯 收藏