[MySQL5.6]PerformanceSchema之PS配置項（1）

zhaiwx_yinfeng發表於2016-05-10
MySqlORM
儘管Performance Schema（以下簡稱PS）在5.5中已經出現，但一直沒有使用過，並且相比5.6，5.5的PS表要少很多。 以下從一個初學者的角度，閱讀PS的官方文件，做一些簡單的筆記

1.開啟PS

首先需要強調一點，開啟PS是有效能開銷的，在一個效能測試場景上，我對比了阿里內部版本的Percona Server 5.5.18與官方MySQL5.6.10,發現在同等壓力下，5.6版本有明顯的更高的CPU開銷（大約高了10~20%）

確認是否開啟：
編譯階段：-DWITH_PERFSCHEMA_STORAGE_ENGINE:BOOL=ON    
預設是ON，可以設為OFF來在編譯階段關閉Performance Schema

也可以在啟動mysqld時，關閉選項performance_schema

如果你在error log中看到類似錯誤的PS表結構或者PS表找不到之類的錯誤，在開啟例項後，可以執行一下mysql_upgrade
[ERROR] Native table `performance_schema`.`events_waits_history` has the wrong structure [ERROR] Native table `performance_schema`.`events_waits_history_long` 
has the wrong structure 

2.配置PS


Performance Schema可以通過配置setup表來在執行時配置PS，包括以下幾個表：

mysql> show tables like ‘%setup%`;

+—————————————-+
| Tables_in_performance_schema (%setup%) |
+—————————————-+
| setup_actors                           |
| setup_consumers                        |
| setup_instruments                      |
| setup_objects                          |
| setup_timers                           |
+—————————————-+
5 rows in set (0.00 sec) 

事件的計數設定有兩個相關的表：
performance_timers 列出了可用的時間計數器(timer)及其特徵 

mysql> SELECT * FROM performance_timers;

+————-+—————–+——————+—————-+
| TIMER_NAME  | TIMER_FREQUENCY | TIMER_RESOLUTION | TIMER_OVERHEAD |
+————-+—————–+——————+—————-+
| CYCLE       |      2490706467 |                1 |             38 |
| NANOSECOND  |      1000000000 |                1 |            128 |
| MICROSECOND |         1000000 |                1 |            135 |
| MILLISECOND |            1036 |                1 |            150 |
| TICK        |             103 |                1 |            450 |
+————-+—————–+——————+—————-+ 


其中CYCLE由CPU  cycle counter 來決定timer
TIMER_FREQUENCY表示每秒內的計數次數，對於CYCLE型別和CPU的速度相關。
TICK取決於不同的平臺，例如，在我的機器上，每秒103個tick,tick表示每發生一次timer interrupt的時間間隔，tick的一些概念可以參考網上找到的這篇文章：http://www.360doc.com/content/11/1201/09/1317564_168810003.shtml
TIMER_RESOLUTION表示每次增加計數的單元，如果為10的話，就表示每次值加10
TIMER_OVERHEAD:the minimal number of cycles of overhead to obtain one timing with the given timer

2.1 setup_timers表決定了不同的instrument使用的timer型別

mysql> SELECT * FROM setup_timers;

+———–+————-+
| NAME      | TIMER_NAME  |
+———–+————-+
| idle      | MICROSECOND |
| wait      | CYCLE       |
| stage     | NANOSECOND  | 
| statement | NANOSECOND  |
+———–+————-+
setup_timers 可以配置每種instrument 使用哪種timer, timer必須是performance_timers表中的某一列,可以通過update語句來進行更新 

對於wait型別，最重要的是減少OVERHEAD,所以選擇CYCLE型別，相應的代價是損失計時精度
statement或者stage的執行時間總的來說，相比wait要高一個數量級。為了給statement計時，最重要的是原則是要有一個精確的衡量，並且不受處理器頻率影響，因此預設的為NANOSECOND，其額外的‘OVERHEAD’相比CYCLE TIMER並不明顯，因為呼叫一個timer兩次的開銷（一次是statement開始，一次是statement結束）相比statement執行本身的CPU時間要小很多個數量級。如果使用CYCLE，只有壞處，沒有好處。
cycle計數器的精度依賴於CPU的速度，使用CYCLE 計數器實際上比使用標準gettimeofday的開銷要小，後者的一次呼叫可能產生上百次cycle。

修改 setup_timers 表會立刻生效，所以可能一個事件的開頭和結束使用了兩個不同的timer

2.2setup_instruments 

setup_instruments 表中包含了上述四種型別(idle,wait, stage,statement)對應的的instrument，物件可以通過更新ENABLED和TIMED列來決定是否收集對應事件的資訊 

mysql> select count(*) from  setup_instruments;

+———-+
| count(*) |
+———-+
|      545 |
+———-+
1 row in set (0.00 sec)

mysql> desc setup_instruments;

+———+——————+——+—–+———+——-+
| Field   | Type             | Null | Key | Default | Extra |
+———+——————+——+—–+———+——-+
| NAME    | varchar(128)     | NO   |     | NULL    |       |
| ENABLED | enum(‘YES’,’NO’) | NO   |     | NULL    |       |
| TIMED   | enum(‘YES’,’NO’) | NO   |     | NULL    |       |
+———+——————+——+—–+———+——-+ 


目前5.6.10的版本有545個instrument可以來做配置。其中ENABLED列表示是否為該instrument收集事件，TIMED列表示是否為該instrument計時；如果TIMED列的值被關閉，就不會去為對應的事件生成TIMER_START, TIMER_END, 以及 TIMER_WAIT的值

事件的事件被轉換為納秒來統計，不管是使用哪種timer；這主要是為了使用一個統一的時間單位。

2.3 setup_consumers表 列出了事件資訊的消費者型別

mysql> SELECT * FROM setup_consumers;

+——————————–+———+
| NAME                           | ENABLED |
+——————————–+———+
| events_stages_current          | YES     |
| events_stages_history          | YES     |
| events_stages_history_long     | YES     |
| events_statements_current      | YES     |
| events_statements_history      | YES     |
| events_statements_history_long | YES     |
| events_waits_current           | YES     |
| events_waits_history           | YES     |
| events_waits_history_long      | YES     |
| global_instrumentation         | YES     |
| thread_instrumentation         | YES     |
| statements_digest              | YES     |
+——————————–+———+
12 rows in set (0.00 sec) 


如果你不關注某個consumer，可以關閉掉，這樣伺服器就不會去花費時間來維護。例如，如果你不想使用歷史事件統計，就可以把幾個history事件關閉。主要包括以下幾種consumer：

Global and Thread Consumers
a.global_instrumentation是最高層次的consumer,如果將其設定為NO，就會關閉全域性instrumentation，其他的consumer都會被忽略掉，不管他們被設定成YSE或者NO。 當global_instrumentation被設定為YES時，就會去維護全域性狀態，同樣也會去檢查thread_instrumentation

如果只開啟了global_instrumentation而關閉其他consumer，維護的全域性狀態表包括：

b.只有global_instrumentation為YES時才會去檢查thread_instrumentation。 如果thread_instrumentation為NO，他會禁止執行緒級別或者獨立事件收集資訊。如果設定為YES，則會維護執行緒級別的資訊，同時也會檢查 events_xxx_current consumer 

執行緒級別的資訊所對應的表包括：

Statement Digest Consumer
需要將global_instrumentation設定為YES,否則statements_digest會被忽略掉。它不依賴於 Statement Event consumer，這意味著你可以在每個digest中獲得統計資訊而無需在 events_statements_current中收集資訊，這有利於減少開銷

Wait Event Consumers
這些consumer需要global_instrumentation和thread_instrumentation同時設定為YES.包括以下幾個：
a.events_waits_current,如果設定為NO，則不為 events_waits_current表收集獨立的等待事件。如果為YES，就會開啟 events_waits_current表的資訊收集，同時檢查events_waits_history和events_waits_history_long這兩個consumer。
b.events_waits_history,前提是開啟events_waits_current，該consumer用於控制表events_waits_history中是否收集資訊。
c.events_waits_history_long，前提是開啟events_waits_current，該consumer用於控制表events_waits_history_long中是否收集資訊。

Stage Event Consumers
這些consumer需要global_instrumentation和thread_instrumentation同時設定為YES.包括以下幾個： 

層次關係和Wait Event Consumer類似
events_stages_current ， 對應 events_stages_current表
events_stages_history， 對應events_stages_history表
events_stages_history_long，對應events_stages_history_long表 

Statement Event Consumers
events_statements_current,對應events_statements_current等
events_statements_history， 對應events_statements_history
events_statements_history_long，對應events_statements_history_long 

綜上，consumer級別為：
global_instrumentation
    |–thread_instrumentation
       |–events_waits_current
          |–events_waits_history
          |–events_waits_history_long
       |–events_stages_current
          |–events_stages_history
          |–events_stages_history_long
       |–events_statements_current
          |–events_statements_history
          |–events_statements_history_long
    |– statements_digest
其中高階別的consumer決定是否去檢查低階別的consumer

2.4.setup_objects

setup_objects用於決定哪些物件可以被監控，當前只能控制表物件，該表預設最大可以插入100行記錄，但可以通過引數performance_schema_setup_objects_size來調整其大小 

預設狀態下，該表的資料包括：

mysql> select * from setup_objects;

+————-+——————–+————-+———+——-+
| OBJECT_TYPE | OBJECT_SCHEMA      | OBJECT_NAME | ENABLED | TIMED |
+————-+——————–+————-+———+——-+
| TABLE       | mysql              | %           | NO      | NO    |
| TABLE       | performance_schema | %           | NO      | NO    |
| TABLE       | information_schema | %           | NO      | NO    |
| TABLE       | %                  | %           | YES     | YES   |
+————-+——————–+————-+———+——-+ 

預設情況下，監控的表物件排除mysql/PS/IS庫下的表，其中IS庫下的表，不管是否開啟，都不會去監控。PS會根據 setup_objects 和setup_instruments來決定是否開啟一個instrument併為其計時。對於在setup_objects中的表物件，必須在兩個表中都ENABLED才會收集事件資訊，如果需要計時，則兩者的TIEMD列都必須為YES。

2.5.setup_actors

setup_actors 用於決定新的前臺執行緒的初始監控狀態，預設情況下包括所有使用者：

mysql> select * from  setup_actors;

+——+——+——+
| HOST | USER | ROLE |
+——+——+——+
| %    | %    | %    |
+——+——+——+
1 row in set (0.00 sec)

該表中的記錄可以決定需要對哪些使用者執行緒進行監控，在threads 表中記錄了所有的前臺/後臺執行緒狀態（有點跟PROCESSLIST表類似），並記錄其是否被監控。為了讓threads生效，需要開啟 setup_consumers表中的thread_instrumentation。


相關文章