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

尽管Performance Schema（以下简称PS）在5.5中已经出现，但一直没有使用过，并且相比5.6，5.5的PS表要少很多。以下从一个初学者的角度，阅读PS的官方文档，做一些简单的笔记

官方文档见：http://dev.mysql.com/doc/refman/5.6/en/performance-schema.html

1.开启PS
2.配置PS
2.1 setup_timers表决定了不同的instrument使用的timer类型
2.2setup_instruments
2.3 setup_consumers表列出了事件信息的消费者类型
2.4.setup_objects
2.5.setup_actors

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;

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

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

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

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

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

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

目前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;

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

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

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