金沙国际娱城 > 金沙技术 > 金沙技术数据库对象事件与质量总计 | performanc

原标题:金沙技术数据库对象事件与质量总计 | performanc

浏览次数:133 时间:2019-08-01

原标题:初相识|performance_schema全方位介绍(一)

原标题:数据库对象事件与特性总结 | performance_schema全方位介绍(五)

MySQL Performance-Schema(二) 理论篇,performanceschema

     MySQL Performance-Schema中总共富含54个表,首要分为几类:Setup表,Instance表,Wait Event表,Stage Event表Statement 伊夫nt表,Connection表和Summary表。上一篇小说已经主要讲了Setup表,那篇小说将会独家就每种类型的表做详细的陈诉。

Instance表
     instance中任重(Ren Zhong)而道远涵盖了5张表:cond_instances,file_instances,mutex_instances,rwlock_instances和socket_instances。
(1)cond_instances:条件等待对象实例
表中著录了系统中央银行使的尺度变量的靶子,OBJECT_INSTANCE_BEGIN为对象的内部存款和储蓄器地址。比方线程池的timer_cond实例的name为:wait/synch/cond/threadpool/timer_cond

(2)file_instances:文件实例
表中记录了系统中开辟了文件的靶子,包含ibdata文件,redo文件,binlog文件,用户的表文件等,举个例子redo日志文件:/u01/my3306/data/ib_logfile0。open_count展现当前文件展开的数目,要是重来未有展开过,不会冒出在表中。

(3)mutex_instances:互斥同步对象实例
表中记录了系统中选用互斥量对象的兼具记录,个中name为:wait/synch/mutex/*。举个例子张开文件的互斥量:wait/synch/mutex/mysys/THEnclave_LOCK_open。LOCKED_BY_THREAD_ID显示哪个线程正持有mutex,若未有线程持有,则为NULL。

(4)rwlock_instances: 读写锁同步对象实例
表中著录了系统中选用读写锁对象的具有记录,其中name为 wait/synch/rwlock/*。WRITE_LOCKED_BY_THREAD_ID为正值有着该目的的thread_id,若未有线程持有,则为NULL,READ_LOCKED_BY_COUNT为记录了并且有微微个读者持有读锁。通过 events_waits_current 表能够明白,哪个线程在守候锁;通过rwlock_instances知道哪些线程持有锁。rwlock_instances的症结是,只可以记录持有写锁的线程,对于读锁则无从。

(5)socket_instances:活跃会话对象实例
表中著录了thread_id,socket_id,ip和port,其它表能够透过thread_id与socket_instance举行关联,获取IP-PORT音信,能够与运用接入起来。
event_name重要含有3类:
wait/io/socket/sql/server_unix_socket,服务端unix监听socket
wait/io/socket/sql/server_tcpip_socket,服务端tcp监听socket
wait/io/socket/sql/client_connection,客户端socket

Wait Event表
      Wait表主要涵盖3个表,events_waits_current,events_waits_history和events_waits_history_long,通过thread_id event_id能够唯一鲜明一条记下。current表记录了方今线程等待的风浪,history表记录了各种线程近日等待的十三个事件,而history_long表则记录了不久前有所线程发生的一千0个事件,这里的10和一千0都以能够配备的。这八个表表结构一样,history和history_long表数据都来源于current表。current表和history表中恐怕会有再次事件,并且history表中的事件都以大功告成了的,未有落成的事件不会步向到history表中。
THREAD_ID:线程ID
EVENT_ID:当前线程的事件ID,和THREAD_ID组成多少个Primary Key。
END_EVENT_ID:当事件初始时,这一列棉被服装置为NULL。当事件甘休时,再立异为当前的平地风波ID。
SOURCE:该事件时有爆发时的源码文件
TIMER_START, TIMER_END, TIMER_WAIT:事件始于/截至和等候的日子,单位为阿秒(picoseconds)

OBJECT_SCHEMA, OBJECT_NAME, OBJECT_TYPE视景况而定
对于联合对象(cond, mutex, rwlock),那些3个值均为NULL
对此文本IO对象,OBJECT_SCHEMA为NULL,OBJECT_NAME为文件名,OBJECT_TYPE为FILE
对于SOCKET对象,OBJECT_NAME为该socket的IP:SOCK值
对于表I/O对象,OBJECT_SCHEMA是表的SCHEMA名,OBJECT_NAME是表名,OBJECT_TYPE为TABLE或者TEMPORARY TABLE
NESTING_EVENT_ID:该事件对应的父事件ID
NESTING_EVENT_TYPE:父事件类型(STATEMENT, STAGE, WAIT)
OPERATION:操作类型(lock, read, write)

Stage Event表 

       Stage表首要含有3个表,events_stages_current,events_stages_history和events_stages_history_long,通过thread_id event_id能够独一分明一条记下。表中著录了当下线程所处的施行品级,由于能够理解各类阶段的实行时间,因而通过stage表能够赢得SQL在各种阶段消耗的年月。

THREAD_ID:线程ID
EVENT_ID:事件ID
END_EVENT_ID:刚截止的事件ID
SOURCE:源码地方
TIMER_START, TIMER_END, TIMER_WAIT:事件始于/结束和等待的时光,单位为微秒(picoseconds)
NESTING_EVENT_ID:该事件对应的父事件ID
NESTING_EVENT_TYPE:父事件类型(STATEMENT, STAGE, WAIT)

Statement Event表
      Statement表首要含有3个表,events_statements_current,events_statements_history和events_statements_history_long。通过thread_id event_id能够独一显明一条记下。Statments表只记录最顶层的呼吁,SQL语句或是COMMAND,每条语句一行,对于嵌套的子查询或许存储进度不会单独列出。event_name形式为statement/sql/*,或statement/com/*
SQL_TEXT:记录SQL语句
DIGEST:对SQL_TEXT做MD5发出的三十一人字符串。若是为consumer表中从未展开statement_digest选项,则为NULL。
DIGEST_TEXT:将讲话中值部分用问号替代,用于SQL语句归类。就算为consumer表中未有张开statement_digest选项,则为NULL。
CURRENT_SCHEMA:默许的数码库名
OBJECT_SCHEMA,OBJECT_NAME,OBJECT_TYPE:保留字段,全体为NULL
ROWS_AFFECTED:影响的数据
ROWS_SENT:再次回到的记录数
ROWS_EXAMINED:读取的记录数据
CREATED_TMP_DISK_TABLES:创设物理一时表数目
CREATED_TMP_TABLES:创造不常表数目
SELECT_FULL_JOIN:join时,第一个表为全表扫描的数额
SELECT_FULL_RANGE_JOIN:join时,援引表接纳range格局扫描的数据
SELECT_RANGE:join时,第贰个表采纳range形式扫描的数码
SELECT_SCAN:join时,第2个表位全表扫描的多寡
SORT_ROWS:排序的记录数据
NESTING_EVENT_ID,NESTING_EVENT_TYPE,保留字段,为NULL。

Connection表
     Connection表记录了客户端的新闻,主要不外乎3张表:users,hosts和account表,accounts包罗hosts和users的音讯。
USER:用户名
HOST:用户的IP

Summary表
    Summary表集中了一一维度的总结音讯包含表维度,索引维度,会话维度,语句维度和锁维度的总结消息。
(1).wait-summary表
events_waits_summary_global_by_event_name
现象:按等待事件类型聚合,各个事件一条记下。
events_waits_summary_by_instance
场馆:按等待事件指标聚合,同一种等待事件,恐怕有八个实例,每一个实例有例外的内部存款和储蓄器地址,因而
event_name object_instance_begin独一分明一条记下。
events_waits_summary_by_thread_by_event_name
场所:按每一种线程和事件来总括,thread_id event_name独一鲜明一条记下。
COUNT_STAXC90:事件计数
SUM_TIMER_WAIT:总的等待时间
MIN_TIMER_WAIT:最小等待时间
MAX_TIMER_WAIT:最大等待时间
AVG_TIMER_WAIT:平均等待时间

(2).stage-summary表
events_stages_summary_by_thread_by_event_name
events_stages_summary_global_by_event_name
与后边类似

(3).statements-summary表
events_statements_summary_by_thread_by_event_name表和events_statements_summary_global_by_event_name表与日前类似。对于events_statements_summary_by_digest表,
FIRST_SEEN_TIMESTAMP:第叁个语句试行的时日
LAST_SEEN_TIMESTAMP:最终一个话语推行的光阴
此情此景:用于总计某一段时间内top SQL

(4).file I/O summary表
file_summary_by_event_name [按事件类型计算]
file_summary_by_instance [按实际文件计算]
场景:物理IO维度
FILE_NAME:具体文件名,譬喻:/u01/my3306/data/tcbuyer_0168/tc_biz_order_2695.ibd
EVENT_NAME:事件名,比如:wait/io/file/innodb/innodb_data_file
COUNT_STAR,SUM_TIMER_WAIT,MIN_TIMER_WAIT,AVG_TIMER_WAIT,MAX_TIMER_WAIT
统计IO操作
COUNT_READ,SUM_TIMER_READ,MIN_TIMER_READ,AVG_TIMER_READ,MAX_TIMER_READ, SUM_NUMBER_OF_BYTES_READ
统计读
COUNT_WRITE,SUM_TIMER_WRITE,MIN_TIMER_WRITE,AVG_TIMER_WRITE,MAX_TIMER_WRITE, SUM_NUMBER_OF_BYTES_WRITE
统计写
COUNT_MISC,SUM_TIMER_MISC,MIN_TIMER_MISC,AVG_TIMER_MISC,MAX_TIMER_MISC
总结别的IO事件,比方create,delete,open,close等

(5).Table I/O and Lock Wait Summaries-表
table_io_waits_summary_by_table
根据wait/io/table/sql/handler,聚合每一个表的I/O操作,[逻辑IO]
COUNT_STAR,SUM_TIMER_WAIT,MIN_TIMER_WAIT,AVG_TIMER_WAIT,MAX_TIMER_WAIT
统计IO操作
COUNT_STAR,SUM_TIMER_WAIT,MIN_TIMER_WAIT,AVG_TIMER_WAIT,MAX_TIMER_WAIT
统计读
COUNT_WRITE,SUM_TIMER_WRITE,MIN_TIMER_WRITE,AVG_TIMER_WRITE, MAX_TIMER_WRITE
统计写
COUNT_FETCH,SUM_TIMER_FETCH,MIN_TIMER_FETCH,AVG_TIMER_FETCH, MAX_TIMER_FETCH
与读同样
COUNT_INSERT,SUM_TIMER_INSERT,MIN_TIMER_INSERT,AVG_TIMER_INSERT,MAX_TIMER_INSERT
INSERT总结,相应的还或然有DELETE和UPDATE计算。

(6).table_io_waits_summary_by_index_usage
与table_io_waits_summary_by_table类似,按索引维度总结

(7).table_lock_waits_summary_by_table
集合了表锁等待事件,富含internal lock 和 external lock。
internal lock通过SQL层函数thr_lock调用,OPERATION值为:
read normal
read with shared locks
read high priority
read no insert
write allow write
write concurrent insert
write delayed
write low priority
write normal

external lock则通过接口函数handler::external_lock调用存款和储蓄引擎层,
OPERATION列的值为:
read external
write external

(8).Connection Summaries表
events_waits_summary_by_account_by_event_name
events_waits_summary_by_user_by_event_name
events_waits_summary_by_host_by_event_name
events_stages_summary_by_account_by_event_name
events_stages_summary_by_user_by_event_name
events_stages_summary_by_host_by_event_name
events_statements_summary_by_account_by_event_name
events_statements_summary_by_user_by_event_name
events_statements_summary_by_host_by_event_name

(9).socket-summaries表
socket_summary_by_instance
socket_summary_by_event_name

其它表
performance_timers: 系统协助的总括时间单位
threads: 监视服务端的当下运作的线程

Performance-Schema(二) 理论篇,performanceschema MySQL Performance-Schema中总共包涵51个表,首要分为几类:Setup表,Instance表,Wait Event表,Stage Ev...

     MySQL Performance-Schema中一同蕴涵五15个表,重要分为几类:Setup表,Instance表,Wait 伊夫nt表,Stage Event表Statement 伊夫nt表,Connection表和Summary表。上一篇小说已经紧要讲了Setup表,那篇小说将会分别就每体系型的表做详细的描述。

金沙技术 1

金沙技术 2

Instance表
     instance中重视涵盖了5张表:cond_instances,file_instances,mutex_instances,rwlock_instances和socket_instances。
(1)cond_instances:条件等待对象实例
表中著录了系统中接纳的基准变量的靶子,OBJECT_INSTANCE_BEGIN为对象的内部存款和储蓄器地址。例如线程池的timer_cond实例的name为:wait/synch/cond/threadpool/timer_cond

罗小波·沃趣科技(science and technology)尖端数据库技艺专家

上一篇 《事件总括 | performance_schema全方位介绍》详细介绍了performance_schema的平地风波总计表,但这么些总结数据粒度太粗,仅仅根据事件的5大门类 用户、线程等维度进行分拣总括,但有的时候大家需求从越来越细粒度的维度实行归类总计,比方:某些表的IO成本多少、锁费用多少、以及用户连接的一些质量总计音信等。此时就需求查阅数据库对象事件总计表与品质总结表了。前些天将辅导大家一道踏上排山倒海第五篇的征程(全系共7个篇章),本期将为我们关怀备至授课performance_schema中目的事件总括表与品质总括表。上边,请跟随我们一道初阶performance_schema系统的就学之旅吧~

(2)file_instances:文件实例
表中记录了系统中开发了文本的对象,包含ibdata文件,redo文件,binlog文件,用户的表文件等,比方redo日志文件:/u01/my3306/data/ib_logfile0。open_count展现当前文件张开的多寡,如若重来未有展开过,不会油可是生在表中。

产品:沃趣科学和技术

友情提醒:下文中的总结表中山大学部分字段含义与上一篇 《事件总括 | performance_schema全方位介绍》 中涉嫌的总括表字段含义一样,下文中不再赘述。其余,由于一些计算表中的记录内容过长,限于篇幅会轻松部分文件,如有必要请自行设置MySQL 5.7.11上述版本跟随本文实行同步操作查看。

(3)mutex_instances:互斥同步对象实例
表中记录了系统中应用互斥量对象的有着记录,当中name为:wait/synch/mutex/*。比方展开文件的互斥量:wait/synch/mutex/mysys/THLacrosse_LOCK_open。LOCKED_BY_THREAD_ID展现哪个线程正持有mutex,若未有线程持有,则为NULL。

IT从业多年,历任运维技术员、高端运行工程师、运营首席实施官、数据库程序员,曾子与版本公布系统、轻量级监察和控制系统、运转管理平台、数据库管理平台的规划与编辑,熟练MySQL种类布局,Innodb存款和储蓄引擎,喜好专研开源技艺,追求完美。

01

(4)rwlock_instances: 读写锁同步对象实例
表中著录了系统中使用读写锁对象的有所记录,当中name为 wait/synch/rwlock/*。WRITE_LOCKED_BY_THREAD_ID为正值有着该目的的thread_id,若未有线程持有,则为NULL,READ_LOCKED_BY_COUNT为记录了并且有微微个读者持有读锁。通过 events_waits_current 表能够通晓,哪个线程在等待锁;通过rwlock_instances知道哪些线程持有锁。rwlock_instances的老毛病是,只可以记录持有写锁的线程,对于读锁则无从。

|目 录1、什么是performance_schema

数据库对象总结表

(5)socket_instances:活跃会话对象实例
表中记录了thread_id,socket_id,ip和port,其它表能够经过thread_id与socket_instance进行关联,获取IP-PORT新闻,能够与运用接入起来。
event_name重要含有3类:
wait/io/socket/sql/server_unix_socket,服务端unix监听socket
wait/io/socket/sql/server_tcpip_socket,服务端tcp监听socket
wait/io/socket/sql/client_connection,客户端socket

2、performance_schema使用便捷入门

1.数码库表品级对象等待事件总计

Wait Event表
      Wait表首要涵盖3个表,events_waits_current,events_waits_history和events_waits_history_long,通过thread_id event_id能够唯一鲜明一条记下。current表记录了当下线程等待的事件,history表记录了种种线程近些日子拭目以待的12个事件,而history_long表则记录了近年具有线程发生的10000个事件,这里的10和一千0都以能够配备的。那四个表表结构同样,history和history_long表数据都来自current表。current表和history表中只怕会有重复事件,何况history表中的事件都以瓜熟蒂落了的,未有甘休的平地风波不会参与到history表中。
THREAD_ID:线程ID
EVENT_ID:当前线程的事件ID,和THREAD_ID组成一个Primary Key。
END_EVENT_ID:当事件始于时,这一列被设置为NULL。当事件甘休时,再立异为眼下的风浪ID。
SOURCE:该事件发生时的源码文件
TIMER_START, TIMER_END, TIMER_WAIT:事件开端/截止和等候的小运,单位为微秒(picoseconds)

2.1. 检查当前数据库版本是或不是援救

依照数据库对象名称(库等级对象和表等第对象,如:库名和表名)实行计算的等待事件。根据OBJECT_TYPE、OBJECT_SCHEMA、OBJECT_NAME列进行分组,遵照COUNT_STAR、xxx_TIMER_WAIT字段进行统计。满含一张objects_summary_global_by_type表。

OBJECT_SCHEMA, OBJECT_NAME, OBJECT_TYPE视景况而定
对于联合对象(cond, mutex, rwlock),那个3个值均为NULL
对此文本IO对象,OBJECT_SCHEMA为NULL,OBJECT_NAME为文件名,OBJECT_TYPE为FILE
对于SOCKET对象,OBJECT_NAME为该socket的IP:SOCK值
对于表I/O对象,OBJECT_SCHEMA是表的SCHEMA名,OBJECT_NAME是表名,OBJECT_TYPE为TABLE或者TEMPORARY TABLE
NESTING_EVENT_ID:该事件对应的父事件ID
NESTING_EVENT_TYPE:父事件类型(STATEMENT, STAGE, WAIT)
OPERATION:操作类型(lock, read, write)

2.2. 启用performance_schema

咱俩先来拜见表中记录的计算音讯是怎么体统的。

Stage Event表 

2.3. performance_schema表的归类

admin@localhost : performance _schema 11:10:42> select * from objects_summary _global_by _type where SUM_TIMER_WAIT!=0G;

       Stage表首要涵盖3个表,events_stages_current,events_stages_history和events_stages_history_long,通过thread_id event_id能够独一鲜明一条记下。表中著录了当下线程所处的进行品级,由于能够驾驭种种阶段的实行时间,由此通过stage表能够赢得SQL在各样阶段消耗的年月。

2.4. performance_schema简单布署与使用

*************************** 1. row ***************************

THREAD_ID:线程ID
EVENT_ID:事件ID
END_EVENT_ID:刚甘休的事件ID
SOURCE:源码位置
TIMER_START, TIMER_END, TIMER_WAIT:事件开端/停止和等候的大运,单位为飞秒(picoseconds)
NESTING_EVENT_ID:该事件对应的父事件ID
NESTING_EVENT_TYPE:父事件类型(STATEMENT, STAGE, WAIT)

|导 语非常久在此之前,当自己还在品味着系统地球科学习performance_schema的时候,通过在网络种种找出资料进行学习,但很缺憾,学习的职能并非很猛烈,非常多标称类似 "深入显出performance_schema" 的篇章,基本上都是那种动不动就贴源码的风骨,然后深刻了后来却出不来了。对系统学习performance_schema的效果与利益甚微。

OBJECT_TYPE: TABLE

Statement Event表
      Statement表重要涵盖3个表,events_statements_current,events_statements_history和events_statements_history_long。通过thread_id event_id能够独一鲜明一条记下。Statments表只记录最顶层的央求,SQL语句或是COMMAND,每条语句一行,对于嵌套的子查询可能存款和储蓄进程不会独自列出。event_name形式为statement/sql/*,或statement/com/*
SQL_TEXT:记录SQL语句
DIGEST:对SQL_TEXT做MD5产生的33位字符串。若是为consumer表中绝非展开statement_digest选项,则为NULL。
DIGEST_TEXT:将讲话中值部分用问号替代,用于SQL语句归类。如若为consumer表中平昔不展开statement_digest选项,则为NULL。
CURRENT_SCHEMA:暗中同意的数目库名
OBJECT_SCHEMA,OBJECT_NAME,OBJECT_TYPE:保留字段,全体为NULL
ROWS_AFFECTED:影响的多寡
ROWS_SENT:重回的记录数
ROWS_EXAMINED:读取的笔录数据
CREATED_TMP_DISK_TABLES:创制物理一时表数目
CREATED_TMP_TABLES:成立有时表数目
SELECT_FULL_JOIN:join时,第叁个表为全表扫描的数码
SELECT_FULL_RANGE_JOIN:join时,援引表接纳range格局扫描的多寡
SELECT_RANGE:join时,第一个表选拔range方式扫描的数目
SELECT_SCAN:join时,第八个表位全表扫描的多少
SORT_ROWS:排序的笔录数据
NESTING_EVENT_ID,NESTING_EVENT_TYPE,保留字段,为NULL。

现行反革命,很高兴的报告大家,大家依据 MySQL 官方文书档案加上大家的印证,整理了一份能够系统学习 performance_schema 的素材分享给大家,为了方便大家阅读,大家整理为了二个密密麻麻,一共7篇小说。下边,请随行我们一同起来performance_schema系统的求学之旅吧。

OBJECT_SCHEMA: xiaoboluo

Connection表
     Connection表记录了客户端的新闻,首要不外乎3张表:users,hosts和account表,accounts满含hosts和users的音信。
USER:用户名
HOST:用户的IP

正文首先,差没多少介绍了什么是performance_schema?它能做怎么样?

OBJECT_NAME: test

Summary表
    Summary表凑集了逐个维度的总结新闻包涵表维度,索引维度,会话维度,语句维度和锁维度的总括消息。
(1).wait-summary表
events_waits_summary_global_by_event_name
场景:按等待事件类型聚合,各样事件一条记下。
events_waits_summary_by_instance
情形:按等待事件目的聚合,同一种等待事件,或然有多个实例,每一种实例有两样的内部存款和储蓄器地址,因而
event_name object_instance_begin独一分明一条记下。
events_waits_summary_by_thread_by_event_name
意况:按各样线程和事件来计算,thread_id event_name唯一明确一条记下。
COUNT_STALX570:事件计数
SUM_TIMER_WAIT:总的等待时间
MIN_TIMER_WAIT:最小等待时间
MAX_TIMER_WAIT:最大等待时间
AVG_TIMER_WAIT:平均等待时间

然后,简要介绍了什么急速上手使用performance_schema的方法;

COUNT_STAR: 56

(2).stage-summary表
events_stages_summary_by_thread_by_event_name
events_stages_summary_global_by_event_name
与日前类似

末尾,简要介绍了performance_schema中由什么表组成,那么些表大概的成效是什么样。

SUM _TIMER_WAIT: 195829830101250

(3).statements-summary表
events_statements_summary_by_thread_by_event_name表和events_statements_summary_global_by_event_name表与前方类似。对于events_statements_summary_by_digest表,
FIRST_SEEN_TIMESTAMP:第一个语句实行的小运
LAST_SEEN_TIMESTAMP:最终一个言语实施的岁月
此情此景:用于计算某一段时间内top SQL

PS:本种类作品所选拔的数据库版本为 MySQL 官方 5.7.17版本

MIN _TIMER_WAIT: 2971125

(4).file I/O summary表
file_summary_by_event_name [按事件类型总括]
file_summary_by_instance [按实际文件总结]
场景:物理IO维度
FILE_NAME:具体文件名,比方:/u01/my3306/data/tcbuyer_0168/tc_biz_order_2695.ibd
EVENT_NAME:事件名,比如:wait/io/file/innodb/innodb_data_file
COUNT_STAR,SUM_TIMER_WAIT,MIN_TIMER_WAIT,AVG_TIMER_WAIT,MAX_TIMER_WAIT
统计IO操作
COUNT_READ,SUM_TIMER_READ,MIN_TIMER_READ,AVG_TIMER_READ,MAX_TIMER_READ, SUM_NUMBER_OF_BYTES_READ
统计读
COUNT_WRITE,SUM_TIMER_WRITE,MIN_TIMER_WRITE,AVG_TIMER_WRITE,MAX_TIMER_WRITE, SUM_NUMBER_OF_BYTES_WRITE
统计写
COUNT_MISC,SUM_TIMER_MISC,MIN_TIMER_MISC,AVG_TIMER_MISC,MAX_TIMER_MISC
总结别的IO事件,譬如create,delete,open,close等

|1、**什么是performance_schema**

AVG _TIMER_WAIT: 3496961251500

(5).Table I/O and Lock Wait Summaries-表
table_io_waits_summary_by_table
凭仗wait/io/table/sql/handler,聚合每一种表的I/O操作,[逻辑IO]
COUNT_STAR,SUM_TIMER_WAIT,MIN_TIMER_WAIT,AVG_TIMER_WAIT,MAX_TIMER_WAIT
统计IO操作
COUNT_STAR,SUM_TIMER_WAIT,MIN_TIMER_WAIT,AVG_TIMER_WAIT,MAX_TIMER_WAIT
统计读
COUNT_WRITE,SUM_TIMER_WRITE,MIN_TIMER_WRITE,AVG_TIMER_WRITE, MAX_TIMER_WRITE
统计写
COUNT_FETCH,SUM_TIMER_FETCH,MIN_TIMER_FETCH,AVG_TIMER_FETCH, MAX_TIMER_FETCH
与读同样
COUNT_INSERT,SUM_TIMER_INSERT,MIN_TIMER_INSERT,AVG_TIMER_INSERT,MAX_TIMER_INSERT
INSERT总计,相应的还应该有DELETE和UPDATE计算。

MySQL的performance schema 用于监察和控制MySQL server在七个相当的低档其余运作过程中的资源消耗、能源等待等状态,它有着以下特征:

MAX _TIMER_WAIT: 121025235946125

(6).table_io_waits_summary_by_index_usage
与table_io_waits_summary_by_table类似,按索引维度计算

  1. 提供了一种在数据库运营时实时检查server的里边推市价况的格局。performance_schema 数据库中的表使用performance_schema存款和储蓄引擎。该数据库入眼关注数据库运营进度中的质量相关的数额,与information_schema不同,information_schema首要关心server运维进程中的元数据音讯
  2. performance_schema通过监视server的事件来落到实处监视server内部运转情状, “事件”就是server内部活动中所做的任何事情以及对应的流年消耗,利用这么些音信来判别server中的相关财富消耗在了哪儿?一般的话,事件能够是函数调用、操作系统的等候、SQL语句实施的等级(如sql语句推行进度中的parsing 或 sorting阶段)只怕整体SQL语句与SQL语句集结。事件的访谈可以一本万利的提供server中的相关存款和储蓄引擎对磁盘文件、表I/O、表锁等能源的一块调用新闻。
  3. performance_schema中的事件与写入二进制日志中的事件(描述数据修改的events)、事件陈设调整程序(那是一种存款和储蓄程序)的事件差异。performance_schema中的事件记录的是server实行有个别活动对一些财富的损耗、耗费时间、那些移动施行的次数等情状。
  4. performance_schema中的事件只记录在地点server的performance_schema中,其下的这几个表中数据产生变化时不会被写入binlog中,也不会透过复制机制被复制到别的server中。
  5. 当前活蹦乱跳事件、历史事件和事件摘要相关的表中记录的音讯。能提供某些事件的实行次数、使用时间长度。进而可用以解析某些特定线程、特定对象(如mutex或file)相关联的位移。
  6. PERFORMANCE_SCHEMA存款和储蓄引擎使用server源代码中的“检查评确定地点”来贯彻事件数量的采访。对于performance_schema达成机制自作者的代码未有有关的单独线程来检查评定,那与其他功用(如复制或事件计划程序)区别
  7. 收集的风云数量存款和储蓄在performance_schema数据库的表中。那一个表能够选取SELECT语句询问,也能够运用SQL语句更新performance_schema数据库中的表记录(如动态修改performance_schema的setup_*始于的多少个布局表,但要注意:配置表的更换会立时生效,那会潜濡默化多少搜罗)
  8. performance_schema的表中的多少不组织首领久化存款和储蓄在磁盘中,而是保存在内部存款和储蓄器中,一旦服务重视启,这一个多少会舍弃(满含配置表在内的万事performance_schema下的享有数据)
  9. MySQL辅助的持有平桃园事件监察和控制作用都可用,但不一样平台北用来总计事件时间支出的沙漏类型可能会具备出入。

1 row in set (0.00 sec)

(7).table_lock_waits_summary_by_table
群集了表锁等待事件,富含internal lock 和 external lock。
internal lock通过SQL层函数thr_lock调用,OPERATION值为:
read normal
read with shared locks
read high priority
read no insert
write allow write
write concurrent insert
write delayed
write low priority
write normal

performance_schema落成机制服从以下设计目的:

从表中的笔录内容能够看看,按照库xiaoboluo下的表test进行分组,总计了表相关的等候事件调用次数,总括、最小、平均、最大延迟时间音讯,利用这几个音讯,大家能够大约掌握InnoDB中表的拜候效用排名总括情状,一定程度上反应了对存款和储蓄引擎接口调用的作用。

external lock则经过接口函数handler::external_lock调用存款和储蓄引擎层,
OPERATION列的值为:
read external
write external

  1. 启用performance_schema不会促成server的行事发生变化。比如,它不会改动线程调整机制,不会变成查询实施安插(如EXPLAIN)产生变化
  2. 启用performance_schema之后,server会持续不间断地监测,费用比十分的小。不会导致server不可用
  3. 在该兑现机制中并未有扩展新的入眼字或言辞,深入分析器不会调换
  4. 即使performance_schema的监测机制在在那之中对某件事件施行监测失利,也不会影响server寻常运作
  5. 假诺在起来搜罗事件数量时相遇有任何线程正在针对这个事件新闻实行查询,那么查询会优先实践事件数量的搜集,因为事件数量的搜罗是贰个连发不断的长河,而搜索(查询)那么些事件数量仅仅只是在供给查阅的时候才进行搜索。也说不定有些事件数量永世都不会去寻找
  6. 亟需很轻松地增添新的instruments监测点
  7. instruments(事件访问项)代码版本化:假使instruments的代码发生了更换,旧的instruments代码仍是能够一连职业。
  8. 瞩目:MySQL sys schema是一组对象(富含有关的视图、存款和储蓄进度和函数),能够实惠地拜见performance_schema搜集的数额。同时招来的多少可读性也更加高(比方:performance_schema中的时间单位是阿秒,经过sys schema查询时会转变为可读的us,ms,s,min,hour,day等单位),sys schem在5.7.x版本暗中同意安装

2.表I/O等待和锁等待事件总计

(8).Connection Summaries表
events_waits_summary_by_account_by_event_name
events_waits_summary_by_user_by_event_name
events_waits_summary_by_host_by_event_name

|2、performance_schema使用便捷入门

与objects_summary_global_by_type 表总结音信类似,表I/O等待和锁等待事件总结新闻更是精致,细分了每一种表的增加和删除改查的实践次数,总等待时间,最小、最大、平均等待时间,以至精细到有些索引的增加和删除改查的等候时间,表IO等待和锁等待事件instruments(wait/io/table/sql/handler和wait/lock/table/sql/handler )暗中认可开启,在setup_consumers表中无具体的相应配置,暗中认可表IO等待和锁等待事件总括表中就能计算有关事件信息。包蕴如下几张表:

events_stages_summary_by_account_by_event_name
events_stages_summary_by_user_by_event_name
events_stages_summary_by_host_by_event_name

现行反革命,是或不是感到下边包车型地铁介绍内容太过雅淡呢?假设您那样想,这就对了,小编那时候学习的时候也是如此想的。但现行反革命,对于怎么是performance_schema这么些主题素材上,比起更早以前更清楚了吗?借使你还并未有图谋要抛弃读书本文的话,那么,请跟随大家开首进入到"边走边唱"环节呢!

admin@localhost : performance_schema 06:50:03> show tables like '%table%summary%';

events_statements_summary_by_account_by_event_name
events_statements_summary_by_user_by_event_name
events_statements_summary_by_host_by_event_name

2.1检查当前数据库版本是或不是援助

------------------------------------------------

(9).socket-summaries表
socket_summary_by_instance
socket_summary_by_event_name

performance_schema被视为存款和储蓄引擎。举个例子该引擎可用,则应当在INFORMATION_SCHEMA.ENGINES表或SHOW ENGINES语句的输出中都能够看到它的SUPPORT值为YES,如下:

| Tables_in_performance_schema (%table%summary%) |

其它表
performance_timers: 系统协理的计算时间单位
threads: 监视服务端的近年来运营的线程

使用 INFORMATION_SCHEMA.ENGINES表来查询你的数据库实例是还是不是协理INFORMATION_SCHEMA引擎

------------------------------------------------

qogir_env@localhost : performance_schema 02:41:41> SELECT * FROM INFORMATION_SCHEMA.ENGINES WHERE ENGINE ='PERFORMANCE_SCHEMA';

| table_io_waits_summary_by_index_usage |# 遵照每种索引举行总计的表I/O等待事件

-------------------- --------- -------------------- -------------- ------ ------------

| table_io_waits_summary_by_table |# 根据每种表进行总计的表I/O等待事件

| ENGINE |SUPPORT | COMMENT |TRANSACTIONS | XA |SAVEPOINTS |

| table_lock_waits_summary_by_table |# 依照每一个表张开总计的表锁等待事件

-------------------- --------- -------------------- -------------- ------ ------------

------------------------------------------------

|PERFORMANCE_SCHEMA | YES |Performance Schema | NO |NO | NO |

3rows inset ( 0. 00sec)

-------------------- --------- -------------------- -------------- ------ ------------

作者们先来探视表中记录的总计消息是怎样体统的。

1row inset (0.00sec)

# table_io_waits_summary_by_index_usage表

应用show命令来查询你的数据库实例是或不是帮衬INFORMATION_SCHEMA引擎

admin@localhost : performance _schema 01:55:49> select * from table_io _waits_summary _by_index _usage where SUM_TIMER_WAIT!=0G;

qogir_env@localhost : performance_schema 02:41:54> show engines;

*************************** 1. row ***************************

-------------------- --------- ---------------------------------------------------------------- -------------- ------ ------------

OBJECT_TYPE: TABLE

| Engine |Support | Comment

OBJECT_SCHEMA: xiaoboluo

|Transactions | XA |Savepoints |

OBJECT_NAME: test

-------------------- --------- ---------------------------------------------------------------- -------------- ------ ------------

INDEX_NAME: PRIMARY

......

COUNT_STAR: 1

|PERFORMANCE_SCHEMA | YES |Performance Schema

SUM _TIMER_WAIT: 56688392

| NO |NO | NO |

MIN _TIMER_WAIT: 56688392

......

AVG _TIMER_WAIT: 56688392

9rows inset (0.00sec)

MAX _TIMER_WAIT: 56688392

当大家看出PEEvoqueFORMANCE_SCHEMA 对应的Support 字段输出为YES时就表示大家前段时间的数据库版本是支撑performance_schema的。但知情咱们的实例帮忙performance_schema引擎就可以动用了吧?NO,很可惜,performance_schema在5.6会同在此之前的版本中,默许未有启用,从5.7及其之后的本子才修改为私下认可启用。今后,大家来探访哪些设置performance_schema私下认可启用吧!

COUNT_READ: 1

2.2. 启用performance_schema

SUM _TIMER_READ: 56688392

从上文中大家曾经了然,performance_schema在5.7.x及其以上版本中暗中同意启用(5.6.x及其以下版本暗中认可关闭),要是要显式启用或关闭时,大家要求选拔参数performance_schema=ON|OFF设置,并在my.cnf中举行配置:

MIN _TIMER_READ: 56688392

[mysqld]

AVG _TIMER_READ: 56688392

performance_schema= ON# 注意:该参数为只读参数,须求在实例运转在此之前设置才生效

MAX _TIMER_READ: 56688392

mysqld运行之后,通过如下语句查看performance_schema是还是不是启用生效(值为ON表示performance_schema已开始化成功且能够采纳了。要是值为OFF表示在启用performance_schema时产生一些错误。能够查阅错误日志进行排查):

......

qogir_env@localhost : performance_schema 03:13:10> SHOW VARIABLES LIKE 'performance_schema';

1 row in set (0.00 sec)

-------------------- -------

# table_io_waits_summary_by_table表

| Variable_name |Value |

admin@localhost : performance _schema 01:56:16> select * from table_io _waits_summary _by_table where SUM _TIMER_WAIT!=0G;

-------------------- -------

*************************** 1. row ***************************

|performance_schema | ON |

OBJECT_TYPE: TABLE

-------------------- -------

OBJECT_SCHEMA: xiaoboluo

1row inset (0.00sec)

OBJECT_NAME: test

现行反革命,你可以在performance_schema下利用show tables语句也许经过询问 INFORMATION_SCHEMA.TABLES表中performance_schema引擎相关的元数据来打听在performance_schema下存在着什么表:

COUNT_STAR: 1

通过从INFORMATION_SCHEMA.tables表查询有如何performance_schema引擎的表:

............

qogir_env@localhost : performance_schema 03:13:22> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES

1 row in set (0.00 sec)

WHERE TABLE_SCHEMA ='performance_schema'andengine='performance_schema';

# table_lock_waits_summary_by_table表

------------------------------------------------------

admin@localhost : performance _schema 01:57:20> select * from table_lock _waits_summary _by_table where SUM _TIMER_WAIT!=0G;

| TABLE_NAME |

*************************** 1. row ***************************

------------------------------------------------------

OBJECT_TYPE: TABLE

| accounts |

OBJECT_SCHEMA: xiaoboluo

| cond_instances |

OBJECT_NAME: test

......

............

| users |

COUNT_READ_NORMAL: 0

| variables_by_thread |

SUM_TIMER_READ_NORMAL: 0

------------------------------------------------------

MIN_TIMER_READ_NORMAL: 0

87rows inset (0.00sec)

AVG_TIMER_READ_NORMAL: 0

直接在performance_schema库下使用show tables语句来查看有怎么样performance_schema引擎表:

MAX_TIMER_READ_NORMAL: 0

qogir_env@localhost : performance_schema 03:20:43> use performance_schema

COUNT _READ_WITH _SHARED_LOCKS: 0

Database changed

SUM _TIMER_READ _WITH_SHARED_LOCKS: 0

qogir_env@localhost : performance_schema 03:21:06> show tables from performance_schema;

MIN _TIMER_READ _WITH_SHARED_LOCKS: 0

------------------------------------------------------

AVG _TIMER_READ _WITH_SHARED_LOCKS: 0

| Tables_in_performance_schema |

MAX _TIMER_READ _WITH_SHARED_LOCKS: 0

------------------------------------------------------

......

| accounts |

1 row in set (0.00 sec)

| cond_instances |

从地点表中的笔录消息大家能够见见,table_io_waits_summary_by_index_usage表和table_io_waits_summary_by_table有着相仿的计算列,但table_io_waits_summary_by_table表是带有全部表的增加和删除改查等待事件分类总结,table_io_waits_summary_by_index_usage区分了各类表的目录的增加和删除改查等待事件分类计算,而table_lock_waits_summary_by_table表计算纬度类似,但它是用于计算增加和删除改核对应的锁等待时间,实际不是IO等待时间,那一个表的分组和总括列含义请大家自行融会贯通,这里不再赘言,下边针对这三张表做一些不能缺少的验证:

......

table_io_waits_summary_by_table表:

| users |

该表允许行使TRUNCATE TABLE语句。只将总计列重新设置为零,并非剔除行。对该表实践truncate还有大概会隐式truncate table_io_waits_summary_by_index_usage表

| variables_by_thread |

table_io_waits_summary_by_index_usage表:

------------------------------------------------------

按照与table_io_waits_summary_by_table的分组列 INDEX_NAME列实行分组,INDEX_NAME有如下几种:

87rows inset (0.00sec)

·要是利用到了目录,则这里展示索引的名字,假诺为P本田CR-VIMA中华VY,则意味着表I/O使用到了主键索引

以往,大家掌握了在 MySQL 5.7.17 版本中,performance_schema 下一起有87张表,那么,那87帐表都以存放什么数据的呢?大家怎么选择他们来查询我们想要查看的数额吧?先别发急,大家先来看看那个表是怎么样分类的。

·倘诺值为NULL,则意味表I/O未有选拔到目录

2.3. performance_schema表的归类

·比方是插入操作,则不也许使用到目录,此时的计算值是遵照INDEX_NAME = NULL计算的

performance_schema库下的表能够服从监视不一致的纬度实行了分组,比方:或根据不相同数据库对象开始展览分组,或遵照不相同的平地风波类型进行分组,或在遵循事件类型分组之后,再进一步遵照帐号、主机、程序、线程、用户等,如下:

该表允许行使TRUNCATE TABLE语句。只将计算列复位为零,并不是删除行。该表实行truncate时也会隐式触发table_io_waits_summary_by_table表的truncate操作。其他利用DDL语句改变索引结构时,会导致该表的有所索引计算音讯被重新恢复设置

遵从事件类型分组记录质量事件数量的表

table_lock_waits_summary_by_table表:

言辞事件记录表,那几个表记录了言语事件音讯,当前讲话事件表events_statements_current、历史语句事件表events_statements_history和长语句历史事件表events_statements_history_long、以及集聚后的摘要表summary,在那之中,summary表还足以依赖帐号(account),主机(host),程序(program),线程(thread),用户(user)和大局(global)再拓展剪切)

该表的分组列与table_io_waits_summary_by_table表相同

qogir_env@localhost : performance_schema 03:51:36> show tables like 'events_statement%';

该表满含关于内部和表面锁的新闻:

----------------------------------------------------

·里面锁对应SQL层中的锁。是由此调用thr_lock()函数来贯彻的。(官方手册上说有五个OPERATION列来分别锁类型,该列有效值为:read normal、read with shared locks、read high priority、read no insert、write allow write、write concurrent insert、write delayed、write low priority、write normal。但在该表的概念上并不曾观看该字段)

| Tables_in_performance_schema (%statement%) |

·外表锁对应存款和储蓄引擎层中的锁。通过调用handler::external_lock()函数来落到实处。(官方手册上说有二个OPERATION列来分化锁类型,该列有效值为:read external、write external。但在该表的概念上并从未观看该字段)

----------------------------------------------------

该表允许利用TRUNCATE TABLE语句。只将总括列复位为零,并不是删除行。

| events_statements_current |

3.文件I/O事件总结

| events_statements_history |

文件I/O事件总计表只记录等待事件中的IO事件(不包罗table和socket子种类),文件I/O事件instruments私下认可开启,在setup_consumers表中无实际的关照配置。它包蕴如下两张表:

| events_statements_history_long |

admin@localhost : performance_schema 06:48:12> show tables like '%file_summary%';

| events_statements_summary_by_account_by_event_name |

-----------------------------------------------

| events_statements_summary_by_digest |

| Tables_in_performance_schema (%file_summary%) |

| events_statements_summary_by_host_by_event_name |

-----------------------------------------------

| events_statements_summary_by_program |

| file_summary_by_event_name |

| events_statements_summary_by_thread_by_event_name |

| file_summary_by_instance |

| events_statements_summary_by_user_by_event_name |

-----------------------------------------------

| events_statements_summary_global_by_event_name |

2rows inset ( 0. 00sec)

----------------------------------------------------

两张表中著录的开始和结果很类似:

11rows inset (0.00sec)

·file_summary_by_event_name:依据每种事件名称举行计算的公文IO等待事件

等候事件记录表,与话语事件类型的相关记录表类似:

·file_summary_by_instance:依照各样文件实例(对应现实的各样磁盘文件,比如:表sbtest1的表空间文件sbtest1.ibd)进行总结的文件IO等待事件

qogir_env@localhost : performance_schema 03:53:51> show tables like 'events_wait%';

笔者们先来看看表中著录的总括音信是怎么样子的。

-----------------------------------------------

# file_summary_by_event_name表

| Tables_in_performance_schema (%wait%) |

admin@localhost : performance _schema 11:00:44> select * from file_summary _by_event _name where SUM_TIMER _WAIT !=0 and EVENT_NAME like '%innodb%' limit 1G;

-----------------------------------------------

*************************** 1. row ***************************

| events_waits_current |

EVENT_NAME: wait/io/file/innodb/innodb_data_file

| events_waits_history |

COUNT_STAR: 802

| events_waits_history_long |

SUM_TIMER_WAIT: 412754363625

| events_waits_summary_by_account_by_event_name |

MIN_TIMER_WAIT: 0

| events_waits_summary_by_host_by_event_name |

AVG_TIMER_WAIT: 514656000

| events_waits_summary_by_instance |

MAX_TIMER_WAIT: 9498247500

| events_waits_summary_by_thread_by_event_name |

COUNT_READ: 577

| events_waits_summary_by_user_by_event_name |

SUM_TIMER_READ: 305970952875

| events_waits_summary_global_by_event_name |

MIN_TIMER_READ: 15213375

-----------------------------------------------

AVG_TIMER_READ: 530278875

12rows inset (0.01sec)

MAX_TIMER_READ: 9498247500

等第事件记录表,记录语句实施的级差事件的表,与话语事件类型的连锁记录表类似:

SUM _NUMBER_OF _BYTES_READ: 11567104

qogir_env@localhost : performance_schema 03:55:07> show tables like 'events_stage%';

......

------------------------------------------------

1 row in set (0.00 sec)

| Tables_in_performance_schema (%stage%) |

# file_summary_by_instance表

------------------------------------------------

admin@localhost : performance _schema 11:01:23> select * from file_summary _by_instance where SUM _TIMER_WAIT!=0 and EVENT_NAME like '%innodb%' limit 1G;

| events_stages_current |

*************************** 1. row ***************************

| events_stages_history |

FILE_NAME: /data/mysqldata1/innodb_ts/ibdata1

| events_stages_history_long |

EVENT_NAME: wait/io/file/innodb/innodb_data_file

| events_stages_summary_by_account_by_event_name |

OBJECT _INSTANCE_BEGIN: 139882156936704

| events_stages_summary_by_host_by_event_name |

COUNT_STAR: 33

| events_stages_summary_by_thread_by_event_name |

............

| events_stages_summary_by_user_by_event_name |

1 row in set (0.00 sec)

| events_stages_summary_global_by_event_name |

从下边表中的笔录信息我们得以见到:

------------------------------------------------

·各类文件I/O总括表都有贰个或八个分组列,以表明怎么着计算那些事件音讯。那几个表中的风云名称来自setup_instruments表中的name字段:

8rows inset (0.00sec)

* file_summary_by_event_name表:按照EVENT_NAME列实行分组 ;

事务事件记录表,记录事务相关的风云的表,与话语事件类型的连锁记录表类似:

* file_summary_by_instance表:有额外的FILE_NAME、OBJECT_INSTANCE_BEGIN列,按照FILE_NAME、EVENT_NAME列进行分组,与file_summary_by_event_name 表相比,file_summary_by_instance表多了FILE_NAME和OBJECT_INSTANCE_BEGIN字段,用于记录具体的磁盘文件有关新闻。

qogir_env@localhost : performance_schema 03:55:30> show tables like 'events_transaction%';

·各样文件I/O事件总计表有如下总结字段:

------------------------------------------------------

* COUNT_STAR,SUM_TIMER_WAIT,MIN_TIMER_WAIT,AVG_TIMER_WAIT,MAX_TIMER_WAIT:这一个列总结全数I/O操作数量和操作时间 ;

| Tables_in_performance_schema (%transaction%) |

* COUNT_READ,SUM_TIMER_READ,MIN_TIMER_READ,AVG_TIMER_READ,MAX_TIMER_READ,SUM_NUMBER_OF_BYTES_READ:那一个列总结了具有文件读取操作,包含FGETS,FGETC,FREAD和READ系统调用,还蕴藏了那一个I/O操作的多少字节数 ;

------------------------------------------------------

* COUNT_WRITE,SUM_TIMER_WRITE,MIN_TIMER_WRITE,AVG_TIMER_WRITE,MAX_TIMER_WRITE,SUM_NUMBER_OF_BYTES_W大切诺基ITE:那些列计算了有着文件写操作,满含FPUTS,FPUTC,FP牧马人INTF,VFPEnclaveINTF,FW昂科雷ITE和PW奔驰M级ITE系统调用,还含有了这么些I/O操作的数额字节数 ;

| events_transactions_current |

* COUNT_MISC,SUM_TIMER_MISC,MIN_TIMER_MISC,AVG_TIMER_MISC,MAX_TIMER_MISC:这几个列总计了富有别的文件I/O操作,包含CREATE,DELETE,OPEN,CLOSE,STREAM_OPEN,STREAM_CLOSE,SEEK,TELL,FLUSH,STAT,FSTAT,CHSIZE,RENAME和SYNC系统调用。注意:那么些文件I/O操作未有字节计数新闻。

| events_transactions_history |

文本I/O事件计算表允许行使TRUNCATE TABLE语句。但只将总计列重新载入参数为零,实际不是删除行。

| events_transactions_history_long |

PS:MySQL server使用三种缓存技术通过缓存从文件中读取的新闻来幸免文件I/O操作。当然,若是内部存款和储蓄器非常不足时照旧内存竞争十分大时大概变成查询功用低下,那个时候你可能须求通过刷新缓存或许重启server来让其数额经过文件I/O重回实际不是透过缓存重回。

| events_transactions_summary_by_account_by_event_name |

4.套接字事件总括

| events_transactions_summary_by_host_by_event_name |

套接字事件总括了套接字的读写调用次数和出殡和埋葬接收字节计数音信,socket事件instruments暗中同意关闭,在setup_consumers表中无实际的呼应配置,包蕴如下两张表:

| events_transactions_summary_by_thread_by_event_name |

·socket_summary_by_instance:针对各样socket实例的富有 socket I/O操作,那些socket操作相关的操作次数、时间和出殡和埋葬接收字节音讯由wait/io/socket/* instruments发生。但当连接中断时,在该表中对应socket连接的消息将在被删去(这里的socket是指的前段时间活跃的一连成立的socket实例)

| events_transactions_summary_by_user_by_event_name |

·socket_summary_by_event_name:针对各类socket I/O instruments,这几个socket操作相关的操作次数、时间和出殡和埋葬接收字节消息由wait/io/socket/* instruments发生(这里的socket是指的脚下活跃的连年创制的socket实例)

本文由金沙国际娱城发布于金沙技术,转载请注明出处:金沙技术数据库对象事件与质量总计 | performanc

关键词: perfor 科技 58 AR CES

上一篇:二零一六中关村创办实业余大学街北航学校宣讲

下一篇:没有了