天天看点

MySQL5.6 Performance_schema 深入浅出

22.1 performance schema 快速入门

22.2 performance schema 配置

22.2.1 mysql编译的时候 修改performance schema配置

22.2.2 mysql启动的时候 修改performance schema配置

22.2.3 mysql运行过程中 修改performance schema配置

22.3 performance schema 查询

22.4 performance schema instrument naming conventions

22.5 performance schema status 监控

22.6 performance schema 原子性,分子性 事件

22.7 performance schema statement 诊断

22.8 performance schema 基本表特征

22.9 performance schema 表的描述

22.9.1 performance schema 表的索引

22.9.2 performance schema setup 类型的表

22.9.3 performance schema instance 类型的表

22.9.4 performance schema wait event 类型的表

22.9.5 performance schema stage event 类型的表

22.9.6 performance schema statement event 类型的表

22.9.7 performance schema connection 类型的表

22.9.8 performance schema connection attribute 类型的表

22.9.9 performance schema summary 类型的表

22.9.10 performance schema 其他类型的表

22.10 performance schema 变量与选项

22.11 performance schema 命令选项

22.12 performance schema 系统变量

22.13 performance schema status变量

22.14 performance schema 与插件

22.15 使用performance schema 来诊断问题

22.15.1 使用performance schema来替代profiling

心得: performance_schema的使用

MySQL5.6 Performance_schema 深入浅出
MySQL5.6 Performance_schema 深入浅出
MySQL5.6 Performance_schema 深入浅出
MySQL5.6 Performance_schema 深入浅出
MySQL5.6 Performance_schema 深入浅出

这一节简单的讲解如何使用performance schema,并附上例子。如: section 22.15, “using the performance schema to diagnose problems”

如果要让mysql可用,必须在mysql编译的时候built进来。通过检查服务器的帮助信息,你也可以确认一下perf 是否可用。如果可用,会有一些提示如:

如果以上变量没有出现在你的output上,那么说明你的mysql不支持performance schema。

请关注 section 22.2, “performance schema configuration”.

如果你performance schema被支持,那么在mysql5.6.6开始就已经默认打开的。

如果要显示打开关闭ps,那么就在mysql启动的时候加上performance_schema变量,

并且给予适当的值。比如:在你的my.cnf文件中

一旦这样配置后,当mysql启动时,就会自动初始化performance schema。为了验证初始化是否成功,

可以使用这样的语句:

on表示成功,off表示有错误,请查看相关error log 定位错误。

performance schema 是以存储引擎的方式实现的,你可以通过information_schema.engines 或者

show engines来确认:

你可以像使用正常database一样使用performance schema。

比如:use performance_schema, 以及show语法。

performance_schema数据库名必须是小写。可以使用show create table 查看表:

也可以查询 information_schema.columns来查看列。

performance_schema里面的表可以根据名字分类为:

current events

event histories

summaries

object instances

setup (configuration)

下面有些例子来简单的使用这些表,详细的使用请看:section 22.9, “performance schema table descriptions”.

一开始,不是所有的instrument 和 consumer 都会被enable , 所以一开始他们不会收集所有的事件。

为了让他们都enable 或者 enable event timing。 执行以下两条语句

如果想查看某个时刻的等待事件,可以查询 events_waits_current表。它记录了每个thread最近的监控信息。

这个事件说明 thread 0 在等待86526皮秒 来获得一个锁thr_lock::mutex,而这个锁是mysys子系统中。

以下是列的一些描述

id: thread id

event name:别监控的instrument名字

timer 类型的列: 时间,以皮秒为基准单位

history 表包含了一些列相同事件的历史记录,就如同current-events 一样,不同的是,

有更多的记录来说明服务器最近做了什么,而不是当前做了什么。events_waits_history & events_waits_history_long 记录了每个thread最近10条和10000条event。

如果这个表满了,那么新的event会被加进来,踢掉最老的那个。

summary 表提供了整个时间段的一些统计信息。他们统计事件的处理方式和之前都不一样。

如果想知道某个instrument 被执行的最频繁,或者发生的频率非常高,可以通过排序 events_waits_summary_global_by_event_name表,根据 count_star 或者 sum_timer_wait列。

以上说明thr_lock_malloc 非常hot。

instance 表记录了什么类型的object被instrumented。一个被instrumented的object,当被server使用时就会产生一个event。这些表提供了event名以及简单的阐述。

比如:file_instances 就列出了file io相关的instance of instrument。

setup表用来配置和显示监控信息的。 例如:什么样的timer 被使用,

请查询setup_timers

setup_instruments 列出了哪些event会被收集与监控:

相应了解如何翻译这些instrument 的名字,请看:section 22.4, “performance schema instrument naming conventions”.

为了控制哪些event是不是instrument,可以给enabled设置yes or no。

performance schema 使用收集的events 来更新performance_schema 数据库的那些表,这些表扮演着事件信息消费者的角色。setup_consumers 列出了可用的消费者 以及哪些是enabled。

目前,一般的binary版本都会默认支持ps,不过最后还是想官方的provider 确认一下。

如果使用的是源码包,用cmake with_perfschema_storage_engine 使其ok

如何check是否支持performance schema?

第一:

也可以

注意:show engines 中即便包含了performance_schema,只能说明已经支持,不代表已经开启。

如果要开启,必须在start up阶段设置,请看下一章节。

假设编译的时候已经支持ps,那么mysql5.6.6 版本以及以上版本都会默认enable 。

开启,只需要在my.cnf中

如果server没有足够多的内存用于初始化performance schema,那么它会自己disable 掉,然后没有instrument相关信息。

mysql5.6.4版本开始,允许instrument 和 consumer在server startup阶段配置。之前的版本都

只能在runtime阶段用update配置。

在startup阶段控制instrument,可以用这种形式:

这里面instrument_name 指的是类似wait/synch/mutex/sql/lock_open这种instrument,

value 就是下面其中一种:

off,false, or 0 关闭这个instrument

on,true,or 1 开启这个instrument

counted:开启并且统计这个instrument

--performance-schema-instrument 只能指定一个instrument名字。多个instances可以在多instrument中配置。另外:模式也是被允许的。如:

关闭所有instrument,使用:

在startup阶段控制consumer

这里面$consumer_name 指的是consumer 如:events_waits_history,

$value 为:

off,false,or 0: 不收集这个consumer相关的事件

on,true,or 1 : 收集这个consumer相关的事件

例如:开启events_waits_history consumer,

合法的consumer的名字可以在setup_consumers表中找到。模式匹配是不允许的。

consumer的名字在setup_consumers中以下划线表示,但是在starup 阶段的my.cnf配置文件中,

下划线和横线都是被允许的。

performance schema的默认系统变量:

performance_schema on 和 off 表示是否开启和关闭。其他变量表示:表sizes(number of rows)以及内存分配

一旦开启了performance schema,mysql就会分配内存,这个内存表示最小值,可能会更大,所以

需要根据自己的情况设置一个合理的值。

如果要改变系统变量的值,目前只能在startup阶段修改。如:在my.cnf中:

mysql5.6.6 以及以上版本,如果你不显示的设置系统变量,那么mysql自己会设置默认的值。

setup表:如果你有update权限,可以直接更改监控行为。

如果要查看哪些事件选择了哪些时间,可以查看setup_timers

setup_instruments 列出了哪些instrument事件被收集

setup_consumers 列出了某一类consumer的instrument事件实际被收集

这是一个典型的生产者-消费者模式,即便你设置了setup_instruments=xx,

但是如果setup_consumers没有设置对应的内容(即没有消费者),那么实际的instrument

也不会收集数据到performance schema的表中。

计时事件,主要用于提供事件到底话费了多少时间。当然,你也可以配置不开启计时功能。

以下两个表主要提供timer信息:

performance_timers: 列出了可用的timers和他们的特点

setup_timers : 描述了哪些instrument对应哪些timers

setup_timer是里面的每一条记录都必须是performance_timers里面定义好的内容。

一般都采用picsecond皮秒 作为基准单位。

事件处理是一种典型的生产者-消费者模式

instrument 生产事件,然后被收集。setup_instruments表列出来哪些instrument 可以被收集。

setup_instruments 提供了最基本的形式来控制事件的产生。其他的事件产生形式(如:基于某一个object或者thread)可以参考:section 22.2.3.3, “event pre-filtering”

performan schema里面的那些表,就是用来事件的目的地和消费事件用的。setup_consumers表列出了很多类型的consumer

对于监控事件的过滤分为不同的阶段:

pre-filtering: 修改performance schema的配置(开启或者关闭相应的 instrument 或者 consumer),可以让一部分事件从生产者中收集然后只影响部分consumer. pre-filtering 完成后

会所有用户产生全局影响。

post-filtering: 需要用到一些查询语句(where子句)来过滤。post-filtering是基于用户的不同用户不一样。

pre-filtering 既可以用在 producer , 也可以用在 consumer 中

配置pre-filtering用在 producer上,主要有这些表

setup_instruments : 如果对应的instrument关闭了,那么就不会收集对应event的信息,即便是production-related setup 表。

setup_objects : 控制了是否监控特定对象

threads : 是否每一个thread都会被监控

setup_actors: 决定了哪些host,user,role的foreground thread被监控。

配置pre-filtering用在 consumer上,主要是setup_consumers 这张表。这决定了被收集的event会被发送的目的地。setup_consumers 也会潜在影响production。如果给定的事件没有被配置发送到任何地方(没有consumer),那么performance schema 也不会produce 它。

修改以上表,基本上都会立刻生效。但是也有一些例外:

某些setup_instruments 只在server startup阶段生效,即便你在running 阶段设置也是没有用的。

他们就是: mutexes, conditions, and rwlocks

setup_actors 只影响foreground thread,并且只会对新进来的thread有影响。已经存在的thread不受影响。

即便你修改了以上配置,performance schema不会flush 信息到history表。原来的记录还是存在current-events and history tables ,直到被新的event替换。关闭instrument,也是一样。

当然,你可以truncate table 来情况history历史表。

你也许也想使用truncate 来清空summary类型的表。遗憾的是truncate summary类型的表只会将summary列设置为0或者null,不会删除数据。 events_statements_summary_by_digest例外。

更改立刻生效,部分必须在startup阶段(mutexes, conditions, and rwlocks)

例子:

更改后,立刻生效。

例子1:

例子2:

略。。。

配置修改,立刻生效

关于setup_consumer 的几个基本原则:

和consumer相关的destination 不会接收任何event,除非对于的consumer都开启了

consumer只有等待他所依赖的consumer都enable,才会被check。

如果一个consumer没有被checked通过,或者check了,但是被disable了,那么依赖它的那些consumer不会被check.

如果一个event没有对应的destination(没有对应的consumer),那么会被自动disable.

以下列出consumer的等级关系图:

也就是post-filtering,只不过多了where 从句

名字基本都由‘/’分割,从左到右基本都是从普通粒度到精细粒度。

最上层的instrument 组件

idle

stage

statement

wait

idle instrument 组件

idle event描述来自:socket_instances.state 列: section 22.9.3.5, “the socket_instances table”.

stage instrument 组件

组成形式: stage/code_area/stage_name , code_area 一般是sql or myisam。

stage name 一般来自: show processlist,如:sorting result ,sending data

statement instrument 组件

statement/abstract/* : 一般都是早期的stage,在抽象sql都还没来得及解析的时候。

statement/com: sql 命令操作 如:statement/com/connect

statement/sql: sql语句操作 如:statement/sql/create_db

wait instrument组件

wait/io : io 等待事件

wait/io/file : 文件io等待事件。等待文件操作完成的时间如:fwrite()。

但是物理io有可能因为缓存的原因调用fwrite时不会写磁盘。

wait/io/socket: socket相关的io等待

wait/io/table : 表相关的io等待。一般对于记录rows来说有fetch,insert,update,delete四种操作。

不像其他等待事件,table i/o 还包含了其他的等待事件。比如:table io可能包含了文件io和内存io。因为读取table rows的时候,有可能会去从文件读取数据。

show status like 'perf%'

这些状态表明了由于内存限制,有哪些instrument不能被load或者create。

show engine performance_schema status

这个可以查看status的最大值(.size),以及当前以及达到多少量了(.count)

如:

使用心得: 当(table_share_hash).count=(table_share_hash).size,那么就会增加performance_schema_table_instances_lost的值。这样新的表监控就不会被collect。这时候

可以drop 掉一些不用的表,那么(table_share_hash).count 就会下降。

基本表只允许truncate,select,其他操作都不允许。

variables目前只能重启才能重新配置

重启mysql后,所有状态都会重置

<a href="https://dev.mysql.com/doc/refman/5.6/en/performance-schema.html">https://dev.mysql.com/doc/refman/5.6/en/performance-schema.html</a>

<a href="http://www.markleith.co.uk/2011/04/18/monitoring-table-and-index-io-with-performance_schema/">http://www.markleith.co.uk/2011/04/18/monitoring-table-and-index-io-with-performance_schema/</a>