3

mysql8.0 setup-利来国际app

kevin崔 2021-11-09
413

数据库中对于每条sql语句的资源使用情况统计往往是最头疼的部分,也是最有效定位问题的方式。除此之外,资源使用情况能协助dba确认 是否业务并发量上升,硬件资源满足现有需求,参数是否有必要调整 等情况。
目前mysql提供的机制里还没有类似oracle的awr报告一样做的便利又仔细的,但mysql也提供了单语句profile命令行,实际排查故障中提供了很大的帮助。

目前随着mysql8.0的普遍,官方介绍里profile语句已准备弃用,用performance_schema.setup_actors替代。

profile语句显示当前会话过程中执行的语句的资源使用情况。提供以下信息

指标 说明
all 显示所有性能信息
block io 显示块io操作的次数
context switches 显示上下文切换次数,不管是主动还是被动
cpu 显示用户cpu时间、系统cpu时间
ipc 显示发送和接收的消息数量
memory [当前没有实现]
page faults 显示页错误数量
source 显示源码中的函数名称与位置
swaps 显示swap的次数

其实使用当中,线程级别,人为操作控制确实很麻烦。有事收集信息性能压榨也厉害。

那了解下setup_actors是用什么方式提供资源利用率统计。

setup_actors

从官方的介绍performance_schema下的setup_actors表可用于限制按主机、用户或帐户收集历史事件,以减少运行时开销和历史表中收集的数据量。就是说通过用户级别设置,自动对每条sql统计资源使用情况。这样比原先的profile功能更齐全。

默认情况下,setup_actors被配置为允许对所有前台线程进行监视和历史事件收集:但还是不能收集到相关信息的。但需要开启收集器instruments才可以的。

1)用户设置

mysql> select * from performance_schema.setup_actors; ------ ------ ------ --------- --------- | host | user | role | enabled | history | ------ ------ ------ --------- --------- | % | % | % | yes | yes | ------ ------ ------ --------- --------- 1 row in set (0.00 sec) mysql> update performance_schema.setup_actors set enabled = 'no', history = 'no' where host = '%' and user = '%'; mysql> insert into performance_schema.setup_actors (host,user,role,enabled,history) values('localhost','root','%','yes','yes'); mysql> select * from performance_schema.setup_actors; ----------- ------ ------ --------- --------- | host | user | role | enabled | history | ----------- ------ ------ --------- --------- | % | % | % | no | no | | localhost | root | % | yes | yes | ----------- ------ ------ --------- --------- 2 rows in set (0.00 sec)

2)setup_instruments开启
instruments默认情况下,目前已经开启wait,stage的sql语句,memory 等780个指标监控,就是日常使用的processlist,innodb statu 等信息监控。


通过更新setup_instruments表,确保是启用的。有些指标有可能已经默认启用。范围太广,没有详细的对应关系,就全部开启。

mysql> update performance_schema.setup_instruments set enabled = 'yes', timed = 'yes' where name like '%statement/%'; mysql> update performance_schema.setup_instruments set enabled = 'yes', timed = 'yes' where name like '%stage/%'; mysql> update performance_schema.setup_consumers set enabled = 'yes' where name like '%events_statements_%'; mysql> update performance_schema.setup_consumers set enabled = 'yes' where name like '%events_stages_%';
##查询执行过得sql 时间id mysql> select event_id, truncate(timer_wait/1000000000000,6) as duration, sql_text from performance_schema.events_statements_history_long where sql_text like '%t1%'; ---------- ---------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | event_id | duration | sql_text | ---------- ---------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | 48 | 0.0065 | select *from db1.t1 | | 84 | 0.0004 | select * from db1.t1 | | 41 | 0.0082 | select /*!40001 sql_no_cache */ * from `test1` | ---------- ---------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- #再通过事件id 进行查询,目前只有耗时。 mysql> select event_name as stage, truncate(timer_wait/1000000000000,6) as duration from performance_schema.events_stages_history_long where nesting_event_id=41;


备注:events_stages_history_long表包含n个最近的跨所有线程全局结束的阶段事件。舞台活动直到结束后才会添加到表中。当表已满时,当添加新行时,最老的行将被丢弃,无论哪一个线程生成了这一行。events_stages_history_long表允许使用truncate table方式删除行

字段 说明
thread_id, event_id 开始时 线程id 和 事件id
end_event_id 该列在事件开始时设置为null,并在事件结束时更新为线程当前事件号
event_name 产生事件的仪器的名称。这是setup_instruments表中的name值
source 源文件的名称,其中包含生成事件的经过检测的代码,以及发生检测的文件中的行号
timer_start,timer_end, timer_wai timer_start和timer_end值表示事件计时开始和结束的时间。timer_wait是事件经过的时间(持续时间)。皮秒(万亿分之一秒)
work_completed, work_estimated work_completed表示该阶段已经完成了多少工作单元,work_estimated表示该阶段预计有多少工作单元
nesting_event_id 嵌套该事件的事件的event_id值。事件的嵌套事件通常是语句事件。
nesting_event_type 嵌套事件类型。取值为transaction、statement、stage或wait。

除此之外外events_stages_history_long 表受参数影响,只能记录有限的sql语句,默认1000条

mysql> show variables like '%events_stages_history_long%'; ---------------------------------------------------- ------- | variable_name | value | ---------------------------------------------------- ------- | performance_schema_events_stages_history_long_size | 10000 | ---------------------------------------------------- -------

总结

目前提供的功能非常有限,估计这个功能 应该再磨炼2年才可以。

  • 除了耗时其他无信息。
  • instruments开启关闭,无法重置并恢复初始值。
  • 影响范围和instruments性能消耗,无法评估,还有比较高。
    虽然profile对比不全,但8.0环境中还可以实践使用。
最后修改时间:2021-11-20 22:04:19
「喜欢文章,快来给作者赞赏墨值吧」
【利来手机国际的版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:[email protected]进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论