performance_schema事件计时器配置 - xiaoboluo768/mysql-system-schema GitHub Wiki

  • 事件通过在mysql server的源代码中添加的instruments来收集。instruments通过监视事件执行的时间，就可以提供事件执行过程需要消耗多少时间，当然，事件执行的时间的收集功能也可以通过配置表来进行开关，后续章节会进行介绍

  • performance_schema库下的两个表提供配置事件时间的相关信息，如下：

    • performance_timers表：列出了可用的计时器及其相关特征信息
    • setup_timers表：列出了哪些计时器被应用在哪些类型的instruments上。setup_timers表中出现的每个计时器名称都必须参照performance_timers中列出的定时器，因为定时器的特征信息都记录在performance_timers表中，关于performance_timers表详见3.15.2. performance_timers小节

  • 要修改某事件类型的计时器，可以使用UPDATE操作setup_timers表（注意：虽然你可以通过setup_timers表修改某事件instruments的计时器类型，但是默认情况下，performance_schema的每种instruments使用的计时器类型都是最优的，除非确实有需要，否则不建议修改）：

mysql> SELECT * FROM setup_timers;
+-------------+-------------+
| NAME        | TIMER_NAME  |
+-------------+-------------+
| idle        | MICROSECOND |
| wait        | CYCLE       |
| stage       | NANOSECOND  |
| statement   | NANOSECOND  |
| transaction | NANOSECOND  |
+-------------+-------------+

mysql> UPDATE setup_timers SET TIMER_NAME = 'MICROSECOND' WHERE NAME = 'idle';
mysql> SELECT * FROM setup_timers;
+-------------+-------------+
| NAME        | TIMER_NAME  |
+-------------+-------------+
| idle        | MICROSECOND |
| wait        | CYCLE       |
| stage       | NANOSECOND  |
| statement   | NANOSECOND  |
| transaction | NANOSECOND  |
+-------------+-------------+

  • 其中，NAME值表示计时器应用在哪些事件类型，TIMER_NAME表示这些事件类型当前使用的事件计时器类型

  • setup_timers表，不允许使用TRUNCATE TABLE语句

  • 对于等待事件，最重要的指标是需要减少开销，由于CYCLE计时器会因为CPU时钟频率不同而发生变化，会影响计时器的统计精度，但是使用CYCLE计时器的开销是最小的，因此使用CYCLE计时器是最好的。

  • 对于语句（或阶段）事件，执行的时间通常大于执行单次等待事件所需的时间。对于语句事件的时间，最重要的指标是统计精度，不能受到CPU频率变化的影响，所以使用不基于CPU时钟周期的计时器是最好的。语句事件的默认计时器是NANOSECOND。与CYCLE计时器相比，额外的“开销”并不重要，因为调用计时器两次引起的开销（语句执行开始和结束）本身就比执行语句的CPU时间开销小几个数量级。所以，使用CYCLE计时器在这里没有任何好处

  • CYCLE计时器提供的精度取决于处理器速度。如果处理器运行在1GHz（10亿次/秒）或更高，则CYCLE计时器可提供纳秒级别精度。使用CYCLE计时器比使用实际的时间单位的开销要小得多。例如，标准的gettimeofday（）函数调用本身可能就需要数百个CYCLE，如果使用时间单位计时器，那么此时的开销是不可接受的

  • CYCLE计时器也有缺点：

    • 如果用户希望统计信息中以挂钟的时间单位展示(例如：几分之一秒），则从CYCLE转换到几分之一秒的开销比较昂贵。因此，从CYCLE转换到以秒为单位的计算过程是一个快速而相当粗略的乘法运算
    • 处理器时钟周期速率在每个服务器中可能不同，同一个服务器的CPU时钟频率也会发生变化(例如：当笔记本电脑进入省电模式时，或者当CPU为了降低发热量热降频时)。如果处理器的时钟周期速率发生波动，则从CYCLE转换到实时时间单位将会有误差
    • 根据处理器或操作系统，CYCLE计时器可能不可靠或不可用(例如，在Pentium上，指令是RDTSC（汇编语言而不是C指令）)
    • 一些与无序执行或多处理器同步相关的处理器细节可能会使计数器看起来快或慢（多达1000个CYCLE）

  • MySQL适用于x386（Windows，OS X，Linux，Solaris和其他Unix风格）、PowerPC和IA-64等平台上的CYCLE 计时器

  • 在事件收集信息中，如何使用performance_schema中的计时器：

    • 存储当前事件和历史事件的performance_schema表中的行记录有三列用于表示计时器信息：TIMER_START和TIMER_END表示事件启动和完成的计时器时间点，TIMER_WAIT表示事件持续时间
    • setup_instruments表中有一个ENABLED列，用于设置是否开启收集某事件的instruments。还有一个TIMED列，用于设置某事件instruments是否是计时类型的。如果某事件instruments未启，则不会收集对应的事件信息。如果某事件instruments启用了但是未启用对应的计时功能，则产生的事件记录信息对于TIMER_START，TIMER_END和TIMER_WAIT计时器值都将为NULL。另外，在计算汇总表中的sum，minimum，maximum和average时间值时会忽略这些null值
    • 在内部，当事件计时器开始工作时，事件内的时间都以计时器给定的事件单位存储。但为了在performance_schema表中检索到事件时显示为人可读格式，无论选择哪个计时器，在performance_schema的表中的时间信息都以皮秒（万亿次）显示，以将其统一转换为标准时间单位
    • 对setup_timers表的修改会立即生效，立即影响instruments。正在执行的事件对应的计时器可能会使用修改前的原始计时器作为开始时间，也可能使用修改之后的计时器。为了避免在更改计时器后产生不可预知的监视结果，请在修改计时器之后使用TRUNCATE TABLE语句来重置performance_schema表中的统计信息
    • 在mysqld启动期间performance_schema初始化一个计时器基线（“时间零”）。此时事件记录中的TIMER_START和TIMER_END字段值表示从时间基线以来的皮秒数。TIMER_WAIT值是TIMER_END-TIMER_START的以皮秒为单位的持续时间值
    • 事件中的皮秒值是一个近似值。在某类事件的计时器单位被修改时，它们的统计精确度会受到计时器单位切换的影响。如果使用CYCLE计时器并且CPU速率发生变化，则可能会有漂移现象。由于这些原因，使用事件的TIMER_START值来计算mysqld启动消耗的时间是不合理的（因为精度并不可靠）。但在查询统计信息时使用ORDER BY子句对TIMER_START或TIMER_WAIT值排序是可以的
    • 当等待事件，阶段事件，语句事件或事务事件正在执行时，各个事件类型对应的当前事件表中可以查看当前事件的计时器信息，如下：
events_waits_current
events_stages_current
events_statements_current
events_transactions_current

# 要在这些表中查询当前正在执行的事件消耗了多少时间，可以使用where条件：WHERE END_EVENT_ID IS NULL AND TIMER_WAIT> N

上一篇： 启动时配置 | 下一篇： performance_schema事件过滤配置