-
Notifications
You must be signed in to change notification settings - Fork 111
events_waits_current
xiaoboluo768 edited this page Jun 8, 2020
·
3 revisions
-
events_waits_current表包含当前的等待事件信息,每个线程只显示一行最近监视的等待事件的当前状态
-
在所有包含等待事件行的表中,events_waits_current表是最基础的数据来源。其他包含等待事件数据表在逻辑上是来源于events_waits_current表中的当前事件信息(摘要表除外)。例如,events_waits_history和events_waits_history_long表中的数据是events_waits_current表数据的一个小集合汇总(具体存放多少有相应的变量控制)
-
events_waits_current表字段含义如下:
- THREAD_ID,EVENT_ID:与事件关联的线程ID和当前事件ID。THREAD_ID和EVENT_ID值构成了该事件信息行的唯一标识(不会有重复的THREAD_ID+EVENT_ID值)
- END_EVENT_ID:当一个事件正在执行时该列值为NULL,当一个事件执行结束时把该事件的ID更新到该列
- EVENT_NAME:产生事件的instruments名称。该名称来自setup_instruments表的NAME字段值
- SOURCE:产生该事件的instruments所在的源文件名称以及检测到该事件发生点的代码行号。您可以查看源代码来确定涉及的代码。例如,如果互斥锁、锁被阻塞,您可以检查发生这种情况的上下文环境
- TIMER_START,TIMER_END,TIMER_WAIT:事件的时间信息。单位皮秒(万亿分之一秒)。 TIMER_START和TIMER_END值表示事件开始和结束时间。 TIMER_WAIT是事件经过时间(即事件执行了多长时间)
- 如果事件未执行完成,则TIMER_END为当前计时器时间值(当前时间),TIMER_WAIT为目前为止所经过的时间(TIMER_END - TIMER_START)
- 如果采集该事件的instruments配置项TIMED = NO,则不会收集事件的时间信息,TIMER_START,TIMER_END和TIMER_WAIT在这种情况下均记录为NULL
- SPINS:对于互斥量和自旋次数。如果该列值为NULL,则表示代码中没有使用自旋或者说自旋没有被监控起来
- OBJECT_SCHEMA,OBJECT_NAME,OBJECT_TYPE,OBJECT_INSTANCE_BEGIN:这些列标识了一个正在被执行的对象,所以这些列记录的信息含义需要看对象是什么类型,下面按照不同对象类型分别对这些列的含义进行说明:
- 对于同步对象(cond,mutex,rwlock):
- 1)、OBJECT_SCHEMA,OBJECT_NAME和OBJECT_TYPE列值都为NULL
- 2)、OBJECT_INSTANCE_BEGIN列是内存中同步对象的地址。OBJECT_INSTANCE_BEGIN除了不同的值标记不同的对象之外,其值本身没有意义。但OBJECT_INSTANCE_BEGIN值可用于调试。例如,它可以与GROUP BY OBJECT_INSTANCE_BEGIN子句一起使用来查看1,000个互斥体(例如:保护1,000个页或数据块)上的负载是否是均匀分布还是发生了一些瓶颈。如果在日志文件或其他调试、性能工具中看到与该语句查看的结果中有相同的对象地址,那么,在你分析性能问题时,可以把这个语句查看到的信息与其他工具查看到的信息关联起来。
- 对于文件I/O对象:
- 1)、OBJECT_SCHEMA列值为NULL
- 2)、OBJECT_NAME列是文件名
- 3)、OBJECT_TYPE列为FILE
- 4)、OBJECT_INSTANCE_BEGIN列是内存中的地址,解释同上
- 对于套接字对象:
- 1)、OBJECT_NAME列是套接字的IP:PORT值
- 2)、OBJECT_INSTANCE_BEGIN列是内存中的地址,解释同上
- 对于表I/O对象:
- 1)、OBJECT_SCHEMA列是包含该表的库名称
- 2)、OBJECT_NAME列是表名
- 3)、OBJECT_TYPE列值对于基表或者TEMPORARY TABLE临时表,该值是table,注意:对于在join查询中select_type为DERIVED,subquery等的表可能不记录事件信息也不进行统计
- 4)、OBJECT_INSTANCE_BEGIN列是内存中的地址,解释同上
- 对于同步对象(cond,mutex,rwlock):
- INDEX_NAME:表示使用的索引的名称。 PRIMARY表示使用到了主键。 NULL表示没有使用索引
- NESTING_EVENT_ID:表示该行信息中的EVENT_ID事件是嵌套在哪个事件中,即父事件的EVENT_ID
- NESTING_EVENT_TYPE:表示该行信息中的EVENT_ID事件嵌套的事件的类型。有效值有:TRANSACTION,STATEMENT,STAGE或WAIT,即父事件的事件类型,如果为TRANSACTION则需要到事务事件表中找对应NESTING_EVENT_ID值的事件,其他类型同理
- OPERATION:执行的操作类型,如:lock、read、write、timed_wait等
- NUMBER_OF_BYTES:操作读取或写入的字节数或行数。对于文件IO等待,该列值表示字节数,对于表I/O等待(wait/io/table/sql/handler instruments的事件),该列值表示行数。如果值大于1,则表示该事件对应一个批量I/O操作。以下分别对单个表IO和批量表IO的区别进行描述:
- MySQL的join查询使用嵌套循环实现。performance_schema instruments的作用是在join查询中提供对每个表的扫描行数和执行时间进行统计。示例:join查询语句:SELECT ... FROM t1 JOIN t2 ON ... JOIN t3 ON ...,假设join顺序是t1,t2,t3
- 在join查询中,一个表在查询时与其他表展开联结查询之后,该表的扫描行数可能增加也可能减少,例如:如果t3表扇出大于1,则大多数row fetch操作都是针对t3表,假如join查询从t1表访问10行记录,然后使用t1表驱动查询t2表,t1表的每一行都会扫描t2表的20行记录,然后使用t2表驱动查询t3表,t2表的每一行都会扫描t3表的30行记录,那么,在使用单行输出时,instruments统计操作的事件信息总行数为:10 +(10 * 20)+(10 * 20 * 30)= 6210
- 通过对表中行扫描时的instruments统计操作进行聚合(即,每个t1和t2的扫描行数在instruments统计中可以算作一个批量组合),这样就可以减少instruments统计操作的数量。通过批量I/O输出方式,performance_schema每次对最内层表t3的扫描减少为一个事件统计信息而不是每一行扫描都生成一个事件信息,此时对于instruments统计操作的事件行数量减少到:10 +(10 * 20)+(10 * 20)= 410,这样在该join查询中对于performance_schema中的行统计操作就减少了93%,批量输出策略通过减少输出行数量来显着降低表I/O的performance_schema统计开销。但是相对于每行数据都单独执行统计操作,会损失对时间统计的准确度。在join查询中,批量I/O统计的时间包括用于连接缓冲,聚合和返回行到客户端的操作所花费的时间(即就是整个join语句的执行时间)
- FLAGS:留作将来使用
-
events_waits_current表允许使用TRUNCATE TABLE语句
-
表记录内容示例(由于历史表需要有事务正处于active状态才能抓取到,以下使用events_waits_history 表数据展示)
admin@localhost : performance_schema 06:48:05> select * from events_waits_history where NUMBER_OF_BYTES is not null limit 1\G;
*************************** 1. row ***************************
THREAD_ID: 45
EVENT_ID: 2331
END_EVENT_ID: 2331
EVENT_NAME: wait/io/socket/sql/client_connection
SOURCE: viosocket.c:201
TIMER_START: NULL
TIMER_END: NULL
TIMER_WAIT: NULL
SPINS: NULL
OBJECT_SCHEMA: NULL
OBJECT_NAME: ::ffff:10.10.20.15:56842
INDEX_NAME: NULL
OBJECT_TYPE: SOCKET
OBJECT_INSTANCE_BEGIN: 110667840
NESTING_EVENT_ID: 10
NESTING_EVENT_TYPE: STATEMENT
OPERATION: send
NUMBER_OF_BYTES: 44
FLAGS: NULL
1 row in set (0.00 sec)
- 表定义语句
CREATE TABLE `events_waits_current` (
`THREAD_ID` bigint(20) unsigned NOT NULL,
`EVENT_ID` bigint(20) unsigned NOT NULL,
`END_EVENT_ID` bigint(20) unsigned DEFAULT NULL,
`EVENT_NAME` varchar(128) NOT NULL,
`SOURCE` varchar(64) DEFAULT NULL,
`TIMER_START` bigint(20) unsigned DEFAULT NULL,
`TIMER_END` bigint(20) unsigned DEFAULT NULL,
`TIMER_WAIT` bigint(20) unsigned DEFAULT NULL,
`SPINS` int(10) unsigned DEFAULT NULL,
`OBJECT_SCHEMA` varchar(64) DEFAULT NULL,
`OBJECT_NAME` varchar(512) DEFAULT NULL,
`INDEX_NAME` varchar(64) DEFAULT NULL,
`OBJECT_TYPE` varchar(64) DEFAULT NULL,
`OBJECT_INSTANCE_BEGIN` bigint(20) unsigned NOT NULL,
`NESTING_EVENT_ID` bigint(20) unsigned DEFAULT NULL,
`NESTING_EVENT_TYPE` enum('TRANSACTION','STATEMENT','STAGE','WAIT') DEFAULT NULL,
`OPERATION` varchar(32) NOT NULL,
`NUMBER_OF_BYTES` bigint(20) DEFAULT NULL,
`FLAGS` int(10) unsigned DEFAULT NULL
) ENGINE=PERFORMANCE_SCHEMA DEFAULT CHARSET=utf8
上一篇: socket_instances表 | 下一篇: events_waits_history表
- 验证、测试、整理:罗小波
- QQ:309969177
- 提示:本系列文章的主体结构遵循Oracle MySQL 官方 5.7 手册中,关于information_schema、mysql schema、performance_schema、sys schema的章节结构体系,并额外添加了一些验证、测试数据。鉴于本人精力和能力有限,难免出现一些纰漏,欢迎大家踊跃指正!