當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

5.5的performance_schema

發布時間：2025/3/8 编程问答 25 豆豆

生活随笔收集整理的這篇文章主要介紹了 5.5的performance_schema 小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

http://space.itpub.net/133735/viewspace-684361

mysql? performance_schema 初探：

mysql 5.5 版本新增了一個性能優化的引擎： PERFORMANCE_SCHEMA

這個功能默認是關閉的：

需要設置參數： performance_schema? 才可以啟動該功能，這個參數是靜態參數，只能寫在my.cnf 中

不能動態修改。

先看看有什么東西吧：

mysql> use performance_schema;
Database changed
mysql> show tables ;
+----------------------------------------------+
| Tables_in_performance_schema???????????????? |
+----------------------------------------------+
| cond_instances?????????????????????????????? |
| events_waits_current???????????????????????? |
| events_waits_history???????????????????????? |
| events_waits_history_long??????????????????? |
| events_waits_summary_by_instance???????????? |
| events_waits_summary_by_thread_by_event_name |
| events_waits_summary_global_by_event_name??? |
| file_instances?????????????????????????????? |
| file_summary_by_event_name?????????????????? |
| file_summary_by_instance???????????????????? |
| mutex_instances????????????????????????????? |
| performance_timers?????????????????????????? |
| rwlock_instances???????????????????????????? |
| setup_consumers????????????????????????????? |
| setup_instruments??????????????????????????? |
| setup_timers???????????????????????????????? |
| threads????????????????????????????????????? |
+----------------------------------------------+
17 rows in set (0.00 sec)

這里的數據表分為幾類：

1） setup table ：? 設置表，配置監控選項。

2） current events table : 記錄當前那些thread 正在發生什么事情。

3） history table? 發生的各種事件的歷史記錄表

4） summary table? 對各種事件的統計表

5）雜項表，亂七八糟表。

setup 表：

mysql> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
??? -> WHERE TABLE_SCHEMA = 'performance_schema'
??? -> AND TABLE_NAME LIKE 'setup%';
+-------------------+
| TABLE_NAME??????? |
+-------------------+
| setup_consumers?? |
| setup_instruments |
| setup_timers????? |
+-------------------+

setup_consumers 描述各種事件

setup_instruments 描述這個數據庫下的表名以及是否開啟監控。

setup_timers?? 描述監控選項已經采樣頻率的時間間隔

這個要多說一點目前 performance-schema? 只支持 'wait'? 時間的監控，代碼樹上 wait/ 下的函數都可以監控到。

文檔上說了只有 'wait' 事件的檢測，有沒有其他的選項呢？

看看源代碼：

static row_setup_timers all_setup_timers_data[COUNT_SETUP_TIMERS]=
{
? {
??? { C_STRING_WITH_LEN("wait") },
??? &wait_timer
? }
};

THR_LOCK table_setup_timers::m_table_lock;

int table_setup_timers::update_row_values(TABLE *table,
????????????????????????????????????????? const unsigned char *,
????????????????????????????????????????? unsigned char *,
????????????????????????????????????????? Field **fields)
{
? Field *f;
? longlong value;

? DBUG_ASSERT(m_row);

? for (; (f= *fields) ; fields++)
? {
??? if (bitmap_is_set(table->write_set, f->field_index))
??? {
????? switch(f->field_index)
????? {
????? case 0: /* NAME */
??????? my_error(ER_WRONG_PERFSCHEMA_USAGE, MYF(0));
??????? return HA_ERR_WRONG_COMMAND;
????? case 1: /* TIMER_NAME */
??????? value= get_field_enum(f);
??????? if ((value >= FIRST_TIMER_NAME) && (value <= LAST_TIMER_NAME))
????????? *(m_row->m_timer_name_ptr)= (enum_timer_name) value;
??????? else
????????? return HA_ERR_WRONG_COMMAND;
??????? break;
????? default:
??????? DBUG_ASSERT(false);
????? }
??? }
? }

? return 0;
}

代碼里寫死了，只有 'wait' 一個值，不排除以后的版本會增加新的關鍵字，但至少目前就只有一個啦。
并且這個表的name 字段是不允許修改的的。下面的修改的方法里沒有做任何處理，涉及到name字段的修改，直接報錯。

mysql> SELECT * FROM setup_timers;
+------+------------+
| NAME | TIMER_NAME |
+------+------------+
| wait | CYCLE????? |
+------+------------+
只有 timer_name 可以update 這是一個enum 字段。

性能事件表：

mysql> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
??? -> WHERE TABLE_SCHEMA = 'performance_schema'
??? -> AND TABLE_NAME LIKE '%current';
+----------------------+
| TABLE_NAME?????????? |
+----------------------+
| events_waits_current |
+----------------------+

記錄當前正在發生的等待事件，這個表是只讀的表，不能update ，delete ，但是可以truncate ?

具體字段是什么意思就自己去查doc 了，這里不說了。

性能歷史表：

mysql> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
??? -> WHERE TABLE_SCHEMA = 'performance_schema'
??? -> AND (TABLE_NAME LIKE '%history' OR TABLE_NAME LIKE '%history_long');
+---------------------------+
| TABLE_NAME??????????????? |
+---------------------------+
| events_waits_history????? |
| events_waits_history_long |
+---------------------------+

這些表與前面的性能表的結構是一致的， history 表只保留每個線程（thread）的最近的10個事件， history_long 記錄最近的10000個事件。

新事件如表，如果舊表滿了，就會丟棄舊的數據，標準的先進先出（FIFO)? 這倆表也是只讀表，只能truncate

事件匯總表：

mysql> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
??? -> WHERE TABLE_SCHEMA = 'performance_schema'
??? -> AND TABLE_NAME LIKE '%summary%';
+----------------------------------------------+
| TABLE_NAME?????????????????????????????????? |
+----------------------------------------------+
| events_waits_summary_by_instance???????????? |
| events_waits_summary_by_thread_by_event_name |
| events_waits_summary_global_by_event_name??? |
| file_summary_by_event_name?????????????????? |
| file_summary_by_instance???????????????????? |
+----------------------------------------------+

按照相關的標準對進行的事件統計表，

events_waits_summary_global_by_event_name???? 在mysql5.5.7 以前叫： EVENTS_WAITS_SUMMARY_BY_EVENT_NAME

表也是只讀的，只能turcate

performance? schema? instance 表：

mysql> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
??? -> WHERE TABLE_SCHEMA = 'performance_schema'
??? -> AND TABLE_NAME LIKE '%instances';
+------------------+
| TABLE_NAME?????? |
+------------------+
| cond_instances?? |
| file_instances?? |
| mutex_instances? |
| rwlock_instances |
+------------------+

記錄各種等待事件涉及到的實例? ：? 主要是3類:? cond? (容器？） mutex （互斥鎖），rwlock （讀寫鎖）

這表是只讀的。

亂七八糟表：

mysql> SELECT * FROM performance_timers;
+-------------+-----------------+------------------+----------------+
| TIMER_NAME? | TIMER_FREQUENCY | TIMER_RESOLUTION | TIMER_OVERHEAD |
+-------------+-----------------+------------------+----------------+
| CYCLE?????? |????? 2389029850 |??????????????? 1 |???????????? 72 |
| NANOSECOND? |??????????? NULL |???????????? NULL |?????????? NULL |
| MICROSECOND |???????? 1000000 |??????????????? 1 |??????????? 585 |
| MILLISECOND |??????????? 1035 |??????????????? 1 |??????????? 738 |
| TICK??????? |???????????? 101 |??????????????? 1 |??????????? 630 |
+-------------+-----------------+------------------+----------------+

這個表式只讀表，記錄了事件采樣頻率的設定，我們前面說的setup_timer 表的timer_name 只能區這4個中一個。

mysql> SELECT * FROM threads;
+-----------+----------------+----------------------------------------+
| THREAD_ID | PROCESSLIST_ID | NAME?????????????????????????????????? |
+-----------+----------------+----------------------------------------+
|???????? 0 |????????????? 0 | thread/sql/main??????????????????????? |
|???????? 1 |????????????? 0 | thread/innodb/io_handler_thread??????? |
|??????? 16 |????????????? 0 | thread/sql/signal_handler????????????? |
|??????? 23 |????????????? 7 | thread/sql/one_connection????????????? |
|???????? 5 |????????????? 0 | thread/innodb/io_handler_thread??????? |
|??????? 12 |????????????? 0 | thread/innodb/srv_lock_timeout_thread? |
|??????? 22 |????????????? 6 | thread/sql/one_connection????????????? |

這個表記錄了系統里當前存在的各種線程。

下面就是涉及到performance_schema的各個系統參數了：

mysql> SHOW VARIABLES LIKE 'perf%';
+---------------------------------------------------+---------+
| Variable_name???????????????????????????????????? | Value?? |
+---------------------------------------------------+---------+
| performance_schema??????????????????????????????? | ON????? |
| performance_schema_events_waits_history_long_size | 10000?? |
| performance_schema_events_waits_history_size????? | 10????? |
| performance_schema_max_cond_classes?????????????? | 80????? |
| performance_schema_max_cond_instances???????????? | 1000??? |
| performance_schema_max_file_classes?????????????? | 50????? |
| performance_schema_max_file_handles?????????????? | 32768?? |
| performance_schema_max_file_instances???????????? | 10000?? |
| performance_schema_max_mutex_classes????????????? | 200???? |
| performance_schema_max_mutex_instances??????????? | 1000000 |
| performance_schema_max_rwlock_classes???????????? | 30????? |
| performance_schema_max_rwlock_instances?????????? | 1000000 |
| performance_schema_max_table_handles????????????? | 100000? |
| performance_schema_max_table_instances??????????? | 50000?? |
| performance_schema_max_thread_classes???????????? | 50????? |
| performance_schema_max_thread_instances?????????? | 1000??? |
+---------------------------------------------------+---------+

涉及到系統狀態的參數：
mysql> SHOW STATUS LIKE 'perf%';
+------------------------------------------+-------+
| Variable_name??????????????????????????? | Value |
+------------------------------------------+-------+
| Performance_schema_cond_classes_lost???? | 0???? |
| Performance_schema_cond_instances_lost?? | 0???? |
| Performance_schema_file_classes_lost???? | 0???? |
| Performance_schema_file_handles_lost???? | 0???? |
| Performance_schema_file_instances_lost?? | 0???? |
| Performance_schema_locker_lost?????????? | 0???? |
| Performance_schema_mutex_classes_lost??? | 0???? |
| Performance_schema_mutex_instances_lost? | 0???? |
| Performance_schema_rwlock_classes_lost?? | 0???? |
| Performance_schema_rwlock_instances_lost | 0???? |
| Performance_schema_table_handles_lost??? | 0???? |
| Performance_schema_table_instances_lost? | 0???? |
| Performance_schema_thread_classes_lost?? | 0???? |
| Performance_schema_thread_instances_lost | 0???? |
+------------------------------------------+-------+

如何使用這個，來診斷數據庫性能問題呢？　且聽下回分解！

之前寫過了一個mysql performane schema 的一個介紹，接著因為各種原因，放下了這塊，

這幾天就又撿起來了，就雜七雜八的再寫一點吧：

Mysql Performance Schema
DBA/李思亮
我們使用mysql 5.5 也有一段時間了，對于performance schema 引擎的使用問題，
一直沒有開展起來，主要原因是資料太少。這段時間花了一些時間專門的關注了
一下，形成本文檔：
Mysql 5.5 版本是第一個版本，本文提到的部分數據可能不適用，其中包括了
mysql 5.6 的一些情況。
從數據庫內部講這些表關注了數據庫的4 個模塊
分別是：
1. Mutex （互斥體，鎖相關)
2. RWLOCKs (讀寫鎖）
3. File I/O （文件io）
4. Thread （線程）
包括了全部的mutex 42 個， rwlocks 10 個，以及6 種類型的線程（thread），文
件io 在分為數據(data) , 日志（log），臨時文件（temp file i/o）。
Performance schema 記錄的信息，比較底層，如果想深入的研究，需要對mysql
的internal 有一定的了解，本篇，我們不關注源代碼級的信息，僅從一個使用者
的角度來看，如何使用performance schema 為數據庫優化提供一些建議。
Performance schema 下面的表：
mysql.cnt_it.sock@performance_schema> show tables ;
+----------------------------------------------+
| Tables_in_performance_schema |
+----------------------------------------------+
| cond_instances |
| events_waits_current |
| events_waits_history |
| events_waits_history_long |
| events_waits_summary_by_instance |
| events_waits_summary_by_thread_by_event_name |
| events_waits_summary_global_by_event_name |
| file_instances |
| file_summary_by_event_name |
| file_summary_by_instance |
| mutex_instances |
| performance_timers |
| rwlock_instances |
| setup_consumers |
| setup_instruments |
| setup_timers |
| threads |
+----------------------------------------------+
17 rows in set (0.00 sec)
這些表基本可以分為4部分
一類是instance 表，
Instance 表記錄的是那種類型的對象被探測或者記錄。
instance 表：
mysql> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
-> WHERE TABLE_SCHEMA = 'performance_schema'
-> AND TABLE_NAME LIKE '%instances';
+------------------+
| TABLE_NAME |
+------------------+
| cond_instances |
| file_instances |
| mutex_instances |
| rwlock_instances |
+------------------+
記錄各種等待事件涉及到的實例：主要是3 類: cond (容器？）mutex（互
斥鎖），rwlock （讀寫鎖）
這些表是只讀的。
一類是Setup 表
Setup 表記錄了配置信息，以及監控的參數等等。
setup 表：
mysql> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
-> WHERE TABLE_SCHEMA = 'performance_schema'
-> AND TABLE_NAME LIKE 'setup%';
+-------------------+
| TABLE_NAME |
+-------------------+
| setup_consumers |
| setup_instruments |
| setup_timers |
+-------------------+
setup_consumers 描述各種事件
setup_instruments 描述這個數據庫下的表名以及是否開啟監控。
setup_timers 描述監控選項已經采樣頻率的時間間隔
這個要多說一點目前performance-schema 只支持'wait' 時間的監控，代碼樹
上wait/ 下的函數都可以監控到。
文檔上說了只有'wait' 事件的檢測，有沒有其他的選項呢？
看看源代碼：
static row_setup_timers all_setup_timers_data[COUNT_SETUP_TIMERS]=
{
{
{ C_STRING_WITH_LEN("wait") },
&wait_timer
}
};
THR_LOCK table_setup_timers::m_table_lock;
int table_setup_timers::update_row_values(TABLE *table,
const unsigned char *,
unsigned char *,
Field **fields)
{
Field *f;
longlong value;
DBUG_ASSERT(m_row);
for (; (f= *fields) ; fields++)
{
if (bitmap_is_set(table->write_set, f->field_index))
{
switch(f->field_index)
{
case 0: /* NAME */
my_error(ER_WRONG_PERFSCHEMA_USAGE, MYF(0));
return HA_ERR_WRONG_COMMAND;
case 1: /* TIMER_NAME */
value= get_field_enum(f);
if ((value >= FIRST_TIMER_NAME) && (value <=
LAST_TIMER_NAME))
*(m_row->m_timer_name_ptr)= (enum_timer_name) value;
else
return HA_ERR_WRONG_COMMAND;
break;
default:
DBUG_ASSERT(false);
}
}
}
return 0;
}
代碼里寫死了，只有'wait' 一個值，不排除以后的版本會增加新的關鍵字，但至
少目前就只有一個啦。
并且這個表的name 字段是不允許修改的的。下面的修改的方法里沒有做任何處
理，涉及到name 字段的修改，直接報錯。
mysql> SELECT * FROM setup_timers;
+------+------------+
| NAME | TIMER_NAME |
+------+------------+
| wait | CYCLE |
+------+------------+
只有timer_name 可以update 這是一個enum 字段。
一類是event 表
Event 表記錄了各種事件，提供了當前事件（current），歷史事件（history）以
及history_long 事件，history 表記錄了每個線程的最近的10 個事件，history_long
記錄了10000 個事件。這兩個歷史表都是先進先出（FIFO)的規則。
性能事件表：
mysql> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
-> WHERE TABLE_SCHEMA = 'performance_schema'
-> AND TABLE_NAME LIKE '%current';
+----------------------+
| TABLE_NAME |
+----------------------+
| events_waits_current |
+----------------------+
記錄當前正在發生的等待事件，這個表是只讀的表，不能update ，delete ，但是
可以truncate
具體字段是什么意思就自己去查doc 了，這里不說了。
性能歷史表：
mysql> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
-> WHERE TABLE_SCHEMA = 'performance_schema'
-> AND (TABLE_NAME LIKE '%history' OR TABLE_NAME LIKE
'%history_long');
+---------------------------+
| TABLE_NAME |
+---------------------------+
| events_waits_history |
| events_waits_history_long |
+---------------------------+
這些表與前面的性能表的結構是一致的， history 表只保留每個線程（thread）的
最近的10 個事件， history_long 記錄最近的10000 個事件。
新事件入表，如果舊表滿了，就會丟棄舊的數據，標準的先進先出（FIFO) 這倆
表也是只讀表，只能truncate
還有一類是summary 表
Summary 表是對event 的統計數據。
事件匯總表：
mysql> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
-> WHERE TABLE_SCHEMA = 'performance_schema'
-> AND TABLE_NAME LIKE '%summary%';
+----------------------------------------------+
| TABLE_NAME |
+----------------------------------------------+
| events_waits_summary_by_instance |
| events_waits_summary_by_thread_by_event_name |
| events_waits_summary_global_by_event_name |
| file_summary_by_event_name |
| file_summary_by_instance |
+----------------------------------------------+
按照相關的標準對進行的事件統計表，
events_waits_summary_global_by_event_name 在mysql5.5.7 以前叫：
EVENTS_WAITS_SUMMARY_BY_EVENT_NAME
表也是只讀的，只能turcate
對于performance schema 下的每個表的詳細定義，以及字段的解讀，請參考手冊：
http://dev.mysql.com/doc/refman/5.5/en/performance-schema-table-descriptions.html
大小寫問題
另外一個問題，performance schema 庫下的表，或字段名，在查詢的時候，建議
全部小寫，原因是5.5.5 以前是大寫，導致在某些平臺上
lower_case_table_names =1 出現問題，5.5.8 后全部改為小寫字母。
啟動設置問題
Performance schama 默認是不啟用的，啟動的參數為靜態參數，需要在my.cnf 里
設置performance_schema=1,或者設定命令行參數。
當服務器啟動起來的時候，會在err 日志里記錄一條信息：
“100407 16:13:02 [Note] Buffered information: Performance schema enabled.”
如果是關閉的則會顯示另外一個信息：
“100407 16:13:02 [Note] Buffered information: Performance schema disabled (reason:
start parameters)”
還有中情況，設置了參數但是performance schema 啟動失敗，這種情況極少發生，
日志里的信息：
“Performance schema disabled (reason: init failed)”，啟動失敗情況下，performacne
schema 會關閉自己，并且mysql 數據庫會繼續啟動，起結果就跟關閉啟動參數是
一樣的。
相應的系統參數：
mysql.cnt_it.sock@performance_schema> show global variables like
'%performance_schema%' ;
+---------------------------------------------------+---------+
| Variable_name | Value |
+---------------------------------------------------+---------+
| performance_schema | ON |
| performance_schema_events_waits_history_long_size | 10000 |
| performance_schema_events_waits_history_size | 10 |
| performance_schema_max_cond_classes | 80 |
| performance_schema_max_cond_instances | 1000 |
| performance_schema_max_file_classes | 50 |
| performance_schema_max_file_handles | 32768 |
| performance_schema_max_file_instances | 10000 |
| performance_schema_max_mutex_classes | 200 |
| performance_schema_max_mutex_instances | 1000000 |
| performance_schema_max_rwlock_classes | 30 |
| performance_schema_max_rwlock_instances | 1000000 |
| performance_schema_max_table_handles | 100000 |
| performance_schema_max_table_instances | 50000 |
| performance_schema_max_thread_classes | 50 |
| performance_schema_max_thread_instances | 1000 |
+---------------------------------------------------+---------+
詳解這些參數：
http://dev.mysql.com/doc/refman/5.5/en/performance-schema-system-variables.html
參考mysql 的官方文檔。
對應的狀態參數：
mysql.cnt_house.sock@performance_schema> show global status like
'%performance_schema%' ;
+------------------------------------------+-------+
| Variable_name | Value |
+------------------------------------------+-------+
| Performance_schema_cond_classes_lost | 0 |
| Performance_schema_cond_instances_lost | 0 |
| Performance_schema_file_classes_lost | 0 |
| Performance_schema_file_handles_lost | 0 |
| Performance_schema_file_instances_lost | 0 |
| Performance_schema_locker_lost | 0 |
| Performance_schema_mutex_classes_lost | 0 |
| Performance_schema_mutex_instances_lost | 0 |
| Performance_schema_rwlock_classes_lost | 0 |
| Performance_schema_rwlock_instances_lost | 0 |
| Performance_schema_table_handles_lost | 0 |
| Performance_schema_table_instances_lost | 0 |
| Performance_schema_thread_classes_lost | 0 |
| Performance_schema_thread_instances_lost | 0 |
+------------------------------------------+-------+
14 rows in set (0.00 sec)
參數詳解：
http://dev.mysql.com/doc/refman/5.5/en/performance-schema-status-variables.html
這些狀態值，顯示的是因為內存吃緊，或者系統太忙，導致的一些沒有performance
schema 記錄下來的事件。
對于performance schema 運行狀態如何？
可以使用命令show engine status 來看：
mysql.cnt_house.sock@performance_schema> show engine performance_schema
status \G
*************************** 1. row ***************************
Type: performance_schema
Name: events_waits_current.row_size
Status: 136
*************************** 2. row ***************************
Type: performance_schema
Name: events_waits_current.row_count
Status: 3000
*************************** 3. row ***************************
Type: performance_schema
Name: events_waits_history.row_size
Status: 120
*************************** 4. row ***************************
Type: performance_schema
Name: events_waits_history.row_count
Status: 10000
*************************** 5. row ***************************
Type: performance_schema
Name: events_waits_history.memory
Status: 1200000
*************************** 6. row ***************************
Type: performance_schema
Name: events_waits_history_long.row_size
Status: 120
*************************** 7. row ***************************
Type: performance_schema
Name: events_waits_history_long.row_count
Status: 10000
*************************** 8. row ***************************
Type: performance_schema
Name: events_waits_history_long.memory
Status: 1200000
*************************** 9. row ***************************
Type: performance_schema
Name: (pfs_mutex_class).row_size
Status: 248
*************************** 10. row ***************************
Type: performance_schema
Name: (pfs_mutex_class).row_count
Status: 200
*************************** 11. row ***************************
Type: performance_schema
Name: (pfs_mutex_class).memory
Status: 49600
*************************** 12. row ***************************
Type: performance_schema
Name: (pfs_rwlock_class).row_size
Status: 296
*************************** 13. row ***************************
Type: performance_schema
Name: (pfs_rwlock_class).row_count
Status: 30
*************************** 14. row ***************************
Type: performance_schema
Name: (pfs_rwlock_class).memory
Status: 8880
*************************** 15. row ***************************
Type: performance_schema
Name: (pfs_cond_class).row_size
Status: 216
*************************** 16. row ***************************
Type: performance_schema
Name: (pfs_cond_class).row_count
Status: 80
*************************** 17. row ***************************
Type: performance_schema
Name: (pfs_cond_class).memory
Status: 17280
*************************** 18. row ***************************
Type: performance_schema
Name: (pfs_thread_class).row_size
Status: 136
*************************** 19. row ***************************
Type: performance_schema
Name: (pfs_thread_class).row_count
Status: 50
*************************** 20. row ***************************
Type: performance_schema
Name: (pfs_thread_class).memory
Status: 6800
*************************** 21. row ***************************
Type: performance_schema
Name: (pfs_file_class).row_size
Status: 240
*************************** 22. row ***************************
Type: performance_schema
Name: (pfs_file_class).row_count
Status: 50
*************************** 23. row ***************************
Type: performance_schema
Name: (pfs_file_class).memory
Status: 12000
*************************** 24. row ***************************
Type: performance_schema
Name: mutex_instances.row_size
Status: 136
*************************** 25. row ***************************
Type: performance_schema
Name: mutex_instances.row_count
Status: 1000000
*************************** 26. row ***************************
Type: performance_schema
Name: mutex_instances.memory
Status: 136000000
*************************** 27. row ***************************
Type: performance_schema
Name: rwlock_instances.row_size
Status: 200
*************************** 28. row ***************************
Type: performance_schema
Name: rwlock_instances.row_count
Status: 1000000
*************************** 29. row ***************************
Type: performance_schema
Name: rwlock_instances.memory
Status: 200000000
*************************** 30. row ***************************
Type: performance_schema
Name: cond_instances.row_size
Status: 88
*************************** 31. row ***************************
Type: performance_schema
Name: cond_instances.row_count
Status: 1000
*************************** 32. row ***************************
Type: performance_schema
Name: cond_instances.memory
Status: 88000
*************************** 33. row ***************************
Type: performance_schema
Name: threads.row_size
Status: 504
*************************** 34. row ***************************
Type: performance_schema
Name: threads.row_count
Status: 1000
*************************** 35. row ***************************
Type: performance_schema
Name: threads.memory
Status: 504000
*************************** 36. row ***************************
Type: performance_schema
Name: file_instances.row_size
Status: 624
*************************** 37. row ***************************
Type: performance_schema
Name: file_instances.row_count
Status: 10000
*************************** 38. row ***************************
Type: performance_schema
Name: file_instances.memory
Status: 6240000
*************************** 39. row ***************************
Type: performance_schema
Name: (pfs_file_handle).row_size
Status: 8
*************************** 40. row ***************************
Type: performance_schema
Name: (pfs_file_handle).row_count
Status: 32768
*************************** 41. row ***************************
Type: performance_schema
Name: (pfs_file_handle).memory
Status: 262144
*************************** 42. row ***************************
Type: performance_schema
Name: events_waits_summary_by_thread_by_event_name.row_size
Status: 48
*************************** 43. row ***************************
Type: performance_schema
Name: events_waits_summary_by_thread_by_event_name.row_count
Status: 360000
*************************** 44. row ***************************
Type: performance_schema
Name: events_waits_summary_by_thread_by_event_name.memory
Status: 17280000
*************************** 45. row ***************************
Type: performance_schema
Name: (pfs_table_share).row_size
Status: 488
*************************** 46. row ***************************
Type: performance_schema
Name: (pfs_table_share).row_count
Status: 50000
*************************** 47. row ***************************
Type: performance_schema
Name: (pfs_table_share).memory
Status: 24400000
*************************** 48. row ***************************
Type: performance_schema
Name: (pfs_table).row_size
Status: 72
*************************** 49. row ***************************
Type: performance_schema
Name: (pfs_table).row_count
Status: 100000
*************************** 50. row ***************************
Type: performance_schema
Name: (pfs_table).memory
Status: 7200000
*************************** 51. row ***************************
Type: performance_schema
Name: performance_schema.memory
Status: 394468704
51 rows in set (0.00 sec)
三個命令：
Show engine innodb status
Show engine innodb mutex
Show engine performacne_schema status
統計事件/對象可以分為幾類：
1）wait/io io 等待事件
2）wait/io/file 文件io等待，一般是指等待文件操作完成。
3）wait/sync 等待同步對象，內容比較廣泛，他的time_wait 時間包括了，
請求對一個對象加鎖，因為阻塞而導致的等待時間。
4）wait/sync/cond 主要用于線程間同步，引起的等待事件。
5）wait/sync/mutex 對資源訪問的的互斥體的請求等待，mutex 對資源的
獨占式訪問，的一種鎖結構。
6）wait/sync/rwlock 對變量訪問、修改的鎖等待。主意是對變量，主要用
于線程安全的變量訪問。
這些表的上的操作限制：
對于setup 表上，有些字段是可以update 的，用于控制監控的開啟關閉。
對于event_wait_* 這樣的表式可以truncate 的，但是不能delete，
update。可以在特定的診斷任務開始前，清空原來的數據。
對于summary 的表，也可以執行truncate 操作，但是只是把summary的統
計字段置0或者null ，而不會刪除里面的行記錄。
用performance schema 診斷性能問題的一般步驟：
1.運行測試case
2.打開performance schema 收集信息
3.排除沒有干擾的因素，并關閉對應的收集器，例如確定file i/o 不是問題的根本
原因則可以關閉file io 收集，truncate event 表，然后從新收集性能數據。
4.重復1-3，越來越接近根本原因，也可以從events_waits_history_long
表的統計分析，問題部分會越來越集中。
5.一旦確定了問題的原因，就可以著手解決問題，優化性能。
6.mutex_instances.LOCKED_BY_THREAD_ID 和
rwlock_instances.WRITE_LOCKED_BY_THREAD_ID
這兩個字段對于發現性能瓶頸，或則死鎖是非常重要的。
1）假設thread1 在等待某個mutex
2）那么可以看看thread1 在等待什么資源。
SELECT * FROM events_waits_current WHERE THREAD_ID =
thread_1;
根據其中的OBJECT_INSTANCE_BEGIN 去關聯mutex_instances 表確
定是什么當前資源被那個線程占有，
mysql.cnt_it.sock@performance_schema> SELECT * FROM
mutex_instances where OBJECT_INSTANCE_BEGIN = 15806424;
+------------------------------------+------------------
-----+---------------------+
| NAME | OBJECT_INSTANCE_BEGIN |
LOCKED_BY_THREAD_ID |
+------------------------------------+------------------
-----+---------------------+
| wait/synch/mutex/sql/LOG::LOCK_log |
15805160 | 1305458 |
+------------------------------------+------------------
-----+---------------------+
1 row in set (0.02 sec)
3）。我們就可以去看看這線程當前正在做什么。
mysql.cnt_it.sock@performance_schema> select * from
events_waits_current where thread_id =1305458 \G
*************************** 1. row
***************************
THREAD_ID: 1305458
EVENT_ID: 76094
EVENT_NAME:
wait/synch/cond/sql/MYSQL_BIN_LOG::update_cond
SOURCE: log.cc:5535
TIMER_START: 8958895120369531348
TIMER_END: NULL
TIMER_WAIT: NULL
SPINS: NULL
OBJECT_SCHEMA: NULL
OBJECT_NAME: NULL
OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 15806424
NESTING_EVENT_ID: NULL
OPERATION: timed_wait
NUMBER_OF_BYTES: NULL
FLAGS: 0
1 row in set (0.00 sec)
這是一個示例，我們測試環境，捕捉不到，我就拿了一個bin log 的寫線程。
Sql 示例：
1等待事件的top N
mysql> SELECT EVENT_NAME, SUM(TIMER_WAIT), COUNT(*), SOURCE
-> FROM EVENTS_WAITS_HISTORY_LONG
-> WHERE EVENT_NAME LIKE “%innodb%”
-> GROUP BY SOURCE
-> ORDER BY SUM(TIMER_WAIT) DESC;
2平均等待時間top N :
mysql> SELECT EVENT_NAME, SUM(TIMER_WAIT)/count(*), source
-> FROM EVENTS_WAITS_HISTORY_LONG
-> WHERE EVENT_NAME LIKE “%innodb%”
-> GROUP BY source
-> ORDER BY SUM(TIMER_WAIT) / COUNT(*) DESC;
EVENTS_WAITS_HISTORY 每個線程10 行記錄，
EVENTS_WAITS_HISTORY_LONG 表默認是10000 行記錄，如果認為尺寸不夠
大，可以通過修改參數：
“performance_schema_events_waits_history_size”
“performance_schema_events_waits_history_long_size”
這兩個變量來調整， history_long 表的最大尺寸是100W 行記錄。
3最熱的mutex ：
這里的時間單位是微秒（pico-second，或者說是cpu 頻率周期）
mysql> SELECT EVENT_NAME, COUNT_STAR,SUM_TIMER_WAIT,
AVG_TIMER_WAIT
FROM events_waits_summary_global_by_event_name
WHERE EVENT_NAME LIKE '%innodb%'
order BY COUNT_STAR DESC;
從下面的結果，我們可以大體了解下，我們電腦網計數器的情況：
Buff pool 和日志和undo 是比較忙的，需要優化的。
*************************** 1. row
***************************
EVENT_NAME: wait/synch/mutex/innodb/kernel_mutex
COUNT_STAR: 183768448476
SUM_TIMER_WAIT: 4527315253253694
AVG_TIMER_WAIT: 24635
*************************** 2. row
***************************
EVENT_NAME: wait/synch/mutex/innodb/buf_pool_mutex
COUNT_STAR: 15121853525
SUM_TIMER_WAIT: 3285302101091527
AVG_TIMER_WAIT: 217255
*************************** 3. row
***************************
EVENT_NAME: wait/synch/mutex/innodb/log_sys_mutex
COUNT_STAR: 7142949915
SUM_TIMER_WAIT: 1559525178971936
AVG_TIMER_WAIT: 218330
*************************** 4. row
***************************
EVENT_NAME:
wait/synch/mutex/innodb/log_flush_order_mutex
COUNT_STAR: 6649384948
SUM_TIMER_WAIT: 691589270730534
AVG_TIMER_WAIT: 104008
*************************** 5. row
***************************
EVENT_NAME: wait/synch/mutex/innodb/trx_undo_mutex
COUNT_STAR: 3615217180
SUM_TIMER_WAIT: 112854228995684
AVG_TIMER_WAIT: 31216
PERFORMANCE SCHEMA 的性能問題：
這部分沒有做過測試，數據來自網上
全部默認開啟performance schema 大約會有8% 左右的性能消耗，
如果開啟了performance schema ，但是在setup 表中關閉事件記錄，大約
會有4% 左右的性能損失。
我們的建議：
安裝mysql 的時候，開啟performance schema 參數，
并在setup 表中關閉事件記錄，這樣便于在遇到嚴重問題，需要打開性能日志
的時候，需要重啟mysql

轉載于:https://blog.51cto.com/716378/721973

總結

以上是生活随笔為你收集整理的5.5的performance_schema的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

performance_schema

上一篇：网络管理员必看
下一篇：使用Symantec Altiris 来