• MySQL Performance-Schema(一) 配置篇


          performance-schema最早在MYSQL 5.5中出现,而现在5.6,5.7中performance-Schema又添加了更多的监控项,统计信息也更丰富,越来越有ORACLE-AWR统计信息的赶脚,真乃DBA童鞋进行性能诊断分析的福音。本文主要讲Performance-Schema中的配置表,通过配置表能大概了解performance-schema的全貌,为后续使用和深入理解做准备。

    配置表

    Performance-Schema中主要有5个配置表,具体如下:

    root@performance_schema 06:03:09>show tables like '%setup%';
    +----------------------------------------+
    | Tables_in_performance_schema (%setup%) |
    +----------------------------------------+
    | setup_actors |
    | setup_consumers |
    | setup_instruments |
    | setup_objects |
    | setup_timers |
    +----------------------------------------+

    1.setup_actors用于配置user维度的监控,默认情况下监控所有用户线程。
    root@performance_schema 05:47:27>select * from setup_actors;
    +------+------+------+
    | HOST | USER | ROLE |
    +------+------+------+
    | % | % | % |
    +------+------+------+

    2.setup_consumers表用于配置事件的消费者类型,即收集的事件最终会写入到哪些统计表中。
    root@performance_schema 05:48:16>select * from setup_consumers;
    +--------------------------------+---------+
    | NAME | ENABLED |
    +--------------------------------+---------+
    | events_stages_current | NO |
    | events_stages_history | NO |
    | events_stages_history_long | NO |
    | events_statements_current | YES |
    | events_statements_history | NO |
    | events_statements_history_long | NO |
    | events_waits_current | NO |
    | events_waits_history | NO |
    | events_waits_history_long | NO |
    | global_instrumentation | YES |
    | thread_instrumentation | YES |
    | statements_digest | YES |
    +--------------------------------+---------+
    可以看到有12个consumer,如果不想关注某些consumer,可以将ENABLED设置为NO,比如events_statements_history_long设置为NO,
    则收集事件不会写入到对应的表events_statements_history_long中。12个consumer不是平级的,存在多级层次关系。具体如下表:
    global_instrumentation
     |– thread_instrumentation
       |– events_waits_current
         |– events_waits_history
         |– events_waits_history_long
       |– events_stages_current
         |– events_stages_history
         |– events_stages_history_long
       |– events_statements_current
         |– events_statements_history
         |– events_statements_history_long
     |– statements_digest

    多层次的consumer遵从一个基本原则,只有上一层次的为YES,才会继续检查该本层为YES or NO。global_instrumentation是最高级别consumer,如果它设置为NO,则所有的consumer都会忽略。如果只打开global_instrumentation,而关闭所有其它子consumer(设置为NO),则只收集全局维度的统计信息,比如xxx_instance表,而不会收集用户维度,语句维度的信息。第二层次的是thread_instrumentation,用户线程维度的统计信息,比如xxx_by_thread表,另外一个是statements_digest,这个用于全局统计SQL-digest的信息。第三层次是语句维度,包括events_waits_current,events_stages_current和events_statements_current,分别用于统计wait,stages和statement信息,第四层次是历史表信息,主要包括xxx_history和xxx_history_long。

    3.setup_instruments表用于配置一条条具体的instrument,主要包含4大类:idle,stage/xxx,statement/xxx,wait/xxx.
    root@performance_schema 06:25:50>select name,count(*) from setup_instruments group by LEFT(name,5);
    +---------------------------------+----------+
    | name | count(*) |
    +---------------------------------+----------+
    | idle | 1 |
    | stage/sql/After create | 111 |
    | statement/sql/select | 170 |
    | wait/synch/mutex/sql/PAGE::lock | 296 |
    +---------------------------------+----------+
    idle表示socket空闲的时间,stage类表示语句的每个执行阶段的统计,statement类统计语句维度的信息,wait类统计各种等待事件,比如IO,mutux,spin_lock,condition等。从上表统计结果来看,可以基本看到每类的instrument数目,stage包含111个,statement包含170个,wait包含296个。

    4.setup_objects表用于配置监控对象,默认情况下所有mysql,performance_schema和information_schema中的表都不监控。而其它DB的所有表都监控。

    root@performance_schema 06:25:55>select * from setup_objects;
    +-------------+--------------------+-------------+---------+-------+
    | OBJECT_TYPE | OBJECT_SCHEMA | OBJECT_NAME | ENABLED | TIMED |
    +-------------+--------------------+-------------+---------+-------+
    | TABLE | mysql | % | NO | NO |
    | TABLE | performance_schema | % | NO | NO |
    | TABLE | information_schema | % | NO | NO |
    | TABLE | % | % | YES | YES |
    +-------------+--------------------+-------------+---------+-------+

    5.setup_timers表用于配置每种类型指令的统计时间单位。MICROSECOND表示统计单位是微妙,CYCLE表示统计单位是时钟周期,时间度量与CPU的主频有关,NANOSECOND表示统计单位是纳秒,关于每种类型的具体含义,可以参考performance_timer这个表。由于wait类包含的都是等待事件,单个SQL调用次数比较多,因此选择代价最小的度量单位cycle。但无论采用哪种度量单位,最终统计表中统计的时间都会装换到皮秒。

    root@performance_schema 06:29:50>select * from setup_timers;
    +-----------+-------------+
    | NAME | TIMER_NAME |
    +-----------+-------------+
    | idle | MICROSECOND |
    | wait | CYCLE |
    | stage | NANOSECOND |
    | statement | NANOSECOND |
    +-----------+-------------+

    配置方式

          默认情况下,setup_instruments表只打开了statement和wait/io部分的指令,setup_consumer表中很多consumer也没有打开。为了打开需要的选项,可以通过update语句直接修改配置表,并且修改后可以立即生效,但这种方式必需得启动服务器后才可以修改,并且无法持久化,重启后,又得重新设置一遍。从5.6.4开始提供了my.cnf的配置方式,格式如下:

    1.设置采集的instrument
    performance_schema_instrument='instrument_name=value'
    (1)打开wait类型的指令
    performance_schema_instrument='wait/%'
    (2)打开所有指令
    performance_schema_instrument='%=on'

    2.设置consumer
    performance_schema_consumer_xxx=value
    (1)打开 events_waits_history consumer

    performance_schema_consumer_events_waits_current=on

    performance_schema_consumer_events_waits_history=on

    这里要注意consumer的层次关系, events_waits_history处于第4层,因此设置它时,要确保events_statements_current,thread_instrumentation和global_instrumentation的ENABLED状态都为YES,才能生效。由于默认thread_instrumentation和global_instrumentation都是YES,因此只需要显示设置events_waits_current和events_waits_current即可。

    3.设置统计表大小
    所有的performance_schema表均采用PERFORMANCE_SCHEMA存储引擎,表中的所有数据只存在内存,表的大小在系统初始化时已经
    固定好,因此占用的内存是一定的。可以通过配置来定制具体每个表的记录数。
    performance_schema_events_waits_history_size=20
    performance_schema_events_waits_history_long_size=15000

  • 相关阅读:
    atitit.TokenService v3 qb1 token服务模块的设计 新特性.docx
    Atitit attilax在自然语言处理领域的成果
    Atitit 图像清晰度 模糊度 检测 识别 评价算法 原理
    Atitit (Sketch Filter)素描滤镜的实现  图像处理  attilax总结
    atitit。企业的价值观 员工第一 vs 客户第一.docx
    Atitit 实现java的linq 以及与stream api的比较
    Atitit dsl exer v3 qb3 新特性
    Atititi tesseract使用总结
    Atitit 修改密码的功能流程设计 attilax总结
    atitit.TokenService v3 qb1  token服务模块的设计 新特性.docx
  • 原文地址:https://www.cnblogs.com/zping/p/12132957.html
Copyright © 2020-2023  润新知