佛山网站建设多少钱,河南宝盈建设工程有限公司网站,wordpress foote在哪里,九江濂溪区尽管Performance Schema#xff08;以下简称PS#xff09;在5.5中已经出现#xff0c;但一直没有使用过#xff0c;并且相比5.6#xff0c;5.5的PS表要少很多。 以下从一个初学者的角度#xff0c;阅读PS的官方文档#xff0c;做一些简单的笔记官方文档见#xff1a;ht… 尽管Performance Schema以下简称PS在5.5中已经出现但一直没有使用过并且相比5.65.5的PS表要少很多。 以下从一个初学者的角度阅读PS的官方文档做一些简单的笔记 官方文档见http://dev.mysql.com/doc/refman/5.6/en/performance-schema.html 目录 1.开启PS2.配置PS2.1 setup_timers表决定了不同的instrument使用的timer类型2.2setup_instruments 2.3 setup_consumers表 列出了事件信息的消费者类型2.4.setup_objects2.5.setup_actors 1.开启PS 首先需要强调一点开启PS是有性能开销的在一个性能测试场景上我对比了阿里内部版本的Percona Server 5.5.18与官方MySQL5.6.10,发现在同等压力下5.6版本有明显的更高的CPU开销大约高了10~20% 确认是否开启 编译阶段-DWITH_PERFSCHEMA_STORAGE_ENGINE:BOOLON 默认是ON可以设为OFF来在编译阶段关闭Performance Schema 也可以在启动mysqld时关闭选项performance_schema 如果你在error log中看到类似错误的PS表结构或者PS表找不到之类的错误在开启实例后可以执行一下mysql_upgrade [ERROR] Native table performance_schema.events_waits_history has the wrong structure [ERROR] Native table performance_schema.events_waits_history_long has the wrong structure 2.配置PS Performance Schema可以通过配置setup表来在运行时配置PS包括以下几个表 mysql show tables like ‘%setup%; —————————————- | Tables_in_performance_schema (%setup%) | —————————————- | setup_actors | | setup_consumers | | setup_instruments | | setup_objects | | setup_timers | —————————————- 5 rows in set (0.00 sec) 事件的计数设置有两个相关的表 performance_timers 列出了可用的时间计数器(timer)及其特征 mysql SELECT * FROM performance_timers; ————-—————–———————————- | TIMER_NAME | TIMER_FREQUENCY | TIMER_RESOLUTION | TIMER_OVERHEAD | ————-—————–———————————- | CYCLE | 2490706467 | 1 | 38 | | NANOSECOND | 1000000000 | 1 | 128 | | MICROSECOND | 1000000 | 1 | 135 | | MILLISECOND | 1036 | 1 | 150 | | TICK | 103 | 1 | 450 | ————-—————–———————————- 其中CYCLE由CPU cycle counter 来决定timer TIMER_FREQUENCY表示每秒内的计数次数对于CYCLE类型和CPU的速度相关。 TICK取决于不同的平台例如在我的机器上每秒103个tick,tick表示每发生一次timer interrupt的时间间隔tick的一些概念可以参考网上找到的这篇文章http://www.360doc.com/content/11/1201/09/1317564_168810003.shtml TIMER_RESOLUTION表示每次增加计数的单元如果为10的话就表示每次值加10 TIMER_OVERHEAD:the minimal number of cycles of overhead to obtain one timing with the given timer 2.1 setup_timers表决定了不同的instrument使用的timer类型 mysql SELECT * FROM setup_timers; ———–————- | NAME | TIMER_NAME | ———–————- | idle | MICROSECOND | | wait | CYCLE | | stage | NANOSECOND | | statement | NANOSECOND | ———–————- setup_timers 可以配置每种instrument 使用哪种timer, timer必须是performance_timers表中的某一列,可以通过update语句来进行更新 对于wait类型最重要的是减少OVERHEAD,所以选择CYCLE类型相应的代价是损失计时精度 statement或者stage的执行时间总的来说相比wait要高一个数量级。为了给statement计时最重要的是原则是要有一个精确的衡量并且不受处理器频率影响因此默认的为NANOSECOND其额外的‘OVERHEAD’相比CYCLE TIMER并不明显因为调用一个timer两次的开销一次是statement开始一次是statement结束相比statement执行本身的CPU时间要小很多个数量级。如果使用CYCLE只有坏处没有好处。 cycle计数器的精度依赖于CPU的速度使用CYCLE 计数器实际上比使用标准gettimeofday的开销要小后者的一次调用可能产生上百次cycle。 修改 setup_timers 表会立刻生效所以可能一个事件的开头和结束使用了两个不同的timer 2.2setup_instruments setup_instruments 表中包含了上述四种类型(idle,wait, stage,statement)对应的的instrument对象可以通过更新ENABLED和TIMED列来决定是否收集对应事件的信息 mysql select count(*) from setup_instruments; ———- | count(*) | ———- | 545 | ———- 1 row in set (0.00 sec) mysql desc setup_instruments; ————————————–—————- | Field | Type | Null | Key | Default | Extra | ————————————–—————- | NAME | varchar(128) | NO | | NULL | | | ENABLED | enum(‘YES’,’NO’) | NO | | NULL | | | TIMED | enum(‘YES’,’NO’) | NO | | NULL | | ————————————–—————- 目前5.6.10的版本有545个instrument可以来做配置。其中ENABLED列表示是否为该instrument收集事件TIMED列表示是否为该instrument计时如果TIMED列的值被关闭就不会去为对应的事件生成TIMER_START, TIMER_END, 以及 TIMER_WAIT的值 事件的事件被转换为纳秒来统计不管是使用哪种timer这主要是为了使用一个统一的时间单位。 2.3 setup_consumers表 列出了事件信息的消费者类型 mysql SELECT * FROM setup_consumers; ——————————–——— | NAME | ENABLED | ——————————–——— | events_stages_current | YES | | events_stages_history | YES | | events_stages_history_long | YES | | events_statements_current | YES | | events_statements_history | YES | | events_statements_history_long | YES | | events_waits_current | YES | | events_waits_history | YES | | events_waits_history_long | YES | | global_instrumentation | YES | | thread_instrumentation | YES | | statements_digest | YES | ——————————–——— 12 rows in set (0.00 sec) 如果你不关注某个consumer可以关闭掉这样服务器就不会去花费时间来维护。例如如果你不想使用历史事件统计就可以把几个history事件关闭。主要包括以下几种consumer Global and Thread Consumers a.global_instrumentation是最高层次的consumer,如果将其设置为NO就会关闭全局instrumentation其他的consumer都会被忽略掉不管他们被设置成YSE或者NO。 当global_instrumentation被设置为YES时就会去维护全局状态同样也会去检查thread_instrumentation 如果只打开了global_instrumentation而关闭其他consumer维护的全局状态表包括 mutex_instances rwlock_instances cond_instances file_instances file_summary_by_instance file_summary_by_event_name objects_summary_global_by_type table_lock_waits_summary_by_table table_io_waits_summary_by_index_usage table_io_waits_summary_by_table events_waits_summary_by_instance events_waits_summary_global_by_event_name b.只有global_instrumentation为YES时才会去检查thread_instrumentation。 如果thread_instrumentation为NO他会禁止线程级别或者独立事件收集信息。如果设置为YES则会维护线程级别的信息同时也会检查 events_xxx_current consumer 线程级别的信息所对应的表包括 events_waits_summary_by_thread_by_event_name Statement Digest Consumer 需要将global_instrumentation设置为YES,否则statements_digest会被忽略掉。它不依赖于 Statement Event consumer这意味着你可以在每个digest中获得统计信息而无需在 events_statements_current中收集信息这有利于减少开销 Wait Event Consumers 这些consumer需要global_instrumentation和thread_instrumentation同时设置为YES.包括以下几个 a.events_waits_current,如果设置为NO则不为 events_waits_current表收集独立的等待事件。如果为YES就会开启 events_waits_current表的信息收集同时检查events_waits_history和events_waits_history_long这两个consumer。 b.events_waits_history,前提是打开events_waits_current该consumer用于控制表events_waits_history中是否收集信息。 c.events_waits_history_long前提是打开events_waits_current该consumer用于控制表events_waits_history_long中是否收集信息。 Stage Event Consumers 这些consumer需要global_instrumentation和thread_instrumentation同时设置为YES.包括以下几个 层次关系和Wait Event Consumer类似 events_stages_current 对应 events_stages_current表 events_stages_history 对应events_stages_history表 events_stages_history_long对应events_stages_history_long表 Statement Event Consumers events_statements_current,对应events_statements_current等 events_statements_history 对应events_statements_history events_statements_history_long对应events_statements_history_long 综上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决定是否去检查低级别的consumer 2.4.setup_objects setup_objects用于决定哪些对象可以被监控当前只能控制表对象该表默认最大可以插入100行记录但可以通过参数performance_schema_setup_objects_size来调整其大小 默认状态下该表的数据包括 mysql 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 | ————-——————–————-—————- 默认情况下监控的表对象排除mysql/PS/IS库下的表其中IS库下的表不管是否开启都不会去监控。PS会根据 setup_objects 和setup_instruments来决定是否开启一个instrument并为其计时。对于在setup_objects中的表对象必须在两个表中都ENABLED才会收集事件信息如果需要计时则两者的TIEMD列都必须为YES。 2.5.setup_actors setup_actors 用于决定新的前台线程的初始监控状态默认情况下包括所有用户 mysql select * from setup_actors; —————— | HOST | USER | ROLE | —————— | % | % | % | —————— 1 row in set (0.00 sec) 该表中的记录可以决定需要对哪些用户线程进行监控在threads 表中记录了所有的前台/后台线程状态有点跟PROCESSLIST表类似并记录其是否被监控。为了让threads生效需要打开 setup_consumers表中的thread_instrumentation。
