[MySQL 5.6] Performance Schema 之 PS配置項（1）

盡管performance schema（以下簡稱ps）在5.5中已經出現，但一直沒有使用過，并且相比5.6，5.5的ps表要少很多。 以下從一個初學者的角度，閱讀ps的官方文檔，做一些簡單的筆記

目錄： 

<a href="http://mysqllover.com/?p=522#toc-1-ps">1.開啟ps</a>

<a href="http://mysqllover.com/?p=522#toc-2-ps">2.配置ps</a>

<a href="http://mysqllover.com/?p=522#toc-2-1setup_timersinstrumenttimer">2.1 setup_timers表決定了不同的instrument使用的timer類型</a>

<a href="http://mysqllover.com/?p=522#toc-2-2setup_instruments">2.2setup_instruments </a>

<a href="http://mysqllover.com/?p=522#toc-2-3setup_consumers-">2.3 setup_consumers表 列出了事件資訊的消費者類型</a>

<a href="http://mysqllover.com/?p=522#toc-2-4-setup_objects">2.4.setup_objects</a>

<a href="http://mysqllover.com/?p=522#toc-2-5-setup_actors">2.5.setup_actors</a>

首先需要強調一點，開啟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

has the wrong structure 

performance schema可以通過配置setup表來在運作時配置ps，包括以下幾個表：

mysql&gt; 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) 

事件的計數設定有兩個相關的表：

mysql&gt; 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的速度相關。

timer_resolution表示每次增加計數的單元，如果為10的話，就表示每次值加10

timer_overhead:the minimal number of cycles of overhead to obtain one timing with the given timer

mysql&gt; select * from setup_timers;

+———–+————-+

| name      | timer_name  |

| idle      | microsecond |

| wait      | cycle       |

| stage     | nanosecond  | 

| statement | nanosecond  |

對于wait類型，最重要的是減少overhead,是以選擇cycle類型，相應的代價是損失計時精度

statement或者stage的執行時間總的來說，相比wait要高一個數量級。為了給statement計時，最重要的是原則是要有一個精确的衡量，并且不受處理器頻率影響，是以預設的為nanosecond，其額外的‘overhead’相比cycle timer并不明顯，因為調用一個timer兩次的開銷（一次是statement開始，一次是statement結束）相比statement執行本身的cpu時間要小很多個數量級。如果使用cycle，隻有壞處，沒有好處。

cycle計數器的精度依賴于cpu的速度，使用cycle 計數器實際上比使用标準gettimeofday的開銷要小，後者的一次調用可能産生上百次cycle。

mysql&gt; select count(*) from  setup_instruments;

+———-+

| count(*) |

|      545 |

1 row in set (0.00 sec)

mysql&gt; 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列的值被關閉，就不會去為對應的事件生成<code>timer_start</code>, <code>timer_end</code>, 以及 <code>timer_wait的值</code>

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

mysql&gt; 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)<code></code> 

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

global and thread consumers

a.global_instrumentation是最高層次的consumer,如果将其設定為no，就會關閉全局instrumentation，其他的consumer都會被忽略掉，不管他們被設定成yse或者no。 當global_instrumentation被設定為yes時，就會去維護全局狀态，同樣也會去檢查thread_instrumentation

如果隻打開了global_instrumentation而關閉其他consumer，維護的全局狀态表包括：

<a href="http://dev.mysql.com/doc/refman/5.6/en/mutex-instances-table.html"><code>mutex_instances</code></a>

<a href="http://dev.mysql.com/doc/refman/5.6/en/rwlock-instances-table.html"><code>rwlock_instances</code></a>

<a href="http://dev.mysql.com/doc/refman/5.6/en/cond-instances-table.html"><code>cond_instances</code></a>

<a href="http://dev.mysql.com/doc/refman/5.6/en/file-instances-table.html"><code>file_instances</code></a>

<a href="http://dev.mysql.com/doc/refman/5.6/en/file-summary-tables.html"><code>file_summary_by_instance</code></a>

<a href="http://dev.mysql.com/doc/refman/5.6/en/file-summary-tables.html"><code>file_summary_by_event_name</code></a>

<a href="http://dev.mysql.com/doc/refman/5.6/en/objects-summary-global-by-type-table.html"><code>objects_summary_global_by_type</code></a>

<code>table_lock_waits_summary_by_table</code>

<code>table_io_waits_summary_by_index_usage</code>

<code>table_io_waits_summary_by_table</code>

<a href="http://dev.mysql.com/doc/refman/5.6/en/event-wait-summary-tables.html"><code>events_waits_summary_by_instance</code></a>

<a href="http://dev.mysql.com/doc/refman/5.6/en/event-wait-summary-tables.html"><code>events_waits_summary_global_by_event_name</code></a>

b.隻有global_instrumentation為yes時才會去檢查thread_instrumentation。 如果thread_instrumentation為no，他會禁止線程級别或者獨立事件收集資訊。如果設定為yes，則會維護線程級别的資訊，同時也會檢查 <code>events_<code>xxx</code>_current</code> consumer 

線程級别的資訊所對應的表包括：

<a href="http://dev.mysql.com/doc/refman/5.6/en/event-wait-summary-tables.html"><code>events_waits_summary_by_thread_by_event_name</code></a>

statement digest consumer

<code></code>

wait event consumers

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

stage event consumers

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

層次關系和wait event consumer類似

statement event consumers

<code>綜上，consumer級别為：</code>

global_instrumentation<code></code>

    |–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

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

mysql&gt; 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&gt; select * from  setup_actors;

+——+——+——+

| host | user | role |

| %    | %    | %    |