[MySQL 5.6] Performance Schema 之 PS配置项(1)
官方文檔見:http://dev.mysql.com/doc/refman/5.6/en/performance-schema.html 目錄:?
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,維護的全局狀態表包括:
-
mutex_instances
-
rwlock_instances
-
cond_instances
-
file_instances
-
file_summary_by_instance
-
file_summary_by_event_name
-
objects_summary_global_by_type
-
table_lock_waits_summary_by_table
-
table_io_waits_summary_by_index_usage
-
table_io_waits_summary_by_table
-
events_waits_summary_by_instance
-
events_waits_summary_global_by_event_name
b.只有global_instrumentation為YES時才會去檢查thread_instrumentation。 如果thread_instrumentation為NO,他會禁止線程級別或者獨立事件收集信息。如果設置為YES,則會維護線程級別的信息,同時也會檢查?events_xxx_current?consumer? 線程級別的信息所對應的表包括: events_waits_summary_by_thread_by_event_name
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。
總結
以上是生活随笔為你收集整理的[MySQL 5.6] Performance Schema 之 PS配置项(1)的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 考试的人梦到蛇预示着什么
- 下一篇: poxtfix+dovecot+sasl