• 首页
  • vue
  • TypeScript
  • JavaScript
  • scss
  • css3
  • html5
  • php
  • MySQL
  • redis
  • jQuery
  • 性能架构事件定时

    通过添加到服务器源代码中的工具收集事件。记录时间事件,这是性能模式如何提供事件耗时的概念。也可以将仪器配置为不收集计时信息。本节讨论可用的计时器及其特性,以及如何在事件中表示计时值。

    性能架构计时器

    性能架构计时器的精度和开销量各不相同。要参见可用的计时器及其特性,请参见下performance_timers表:

    mysql> SELECT * FROM performance_schema.performance_timers;
    +-------------	+-----------------	+------------------	+----------------	+
    | TIMER_NAME	| TIMER_FREQUENCY	| TIMER_RESOLUTION	| TIMER_OVERHEAD	|
    +-------------	+-----------------	+------------------	+----------------	+
    | CYCLE	|      2389029850	|                1	|             72	|
    | NANOSECOND	|      1000000000	|                1	|            112	|
    | MICROSECOND	|         1000000	|                1	|            136	|
    | MILLISECOND	|            1036	|                1	|            168	|
    +-------------	+-----------------	+------------------	+----------------	+
    

    如果与给定计时器名称关联的值为NULL,则您的平台不支持该计时器。

    这些列具有以下含义:

    • TIMER_NAME列显示可用计时器的名称。CYCLE指的是基于CPU(处理器)周期计数器的计时器。
    • TIMER_FREQUENCY表示每秒的计时器单位数。对于循环计时器,频率通常与CPU速度有关。显示的值是在配备2.4GHz处理器的系统上获得的。其他计时器基于固定的秒分数。
    • TIMER_RESOLUTION指示计时器单位的数量,计时器值一次增加。如果计时器的分辨率为10,则其值每次都会增加10。
    • TIMER_OVERHEAD是使用给定计时器获得一个时序的最小开销周期数。每个事件的开销是显示值的两倍,因为在事件开始和结束时都会调用计时器。

    性能架构按以下方式分配计时器:

    • 等待计时器使用CYCLE
    • 空闲,阶段,语句和事务计时器NANOSECONDNANOSECOND可用计时器的平台上使用,MICROSECOND否则。

    在服务器启动时,性能模式将验证在构建时对计时器分配所做的假设是否正确,并在计时器不可用时显示警告。

    对于等待事件计时,最重要的标准是减少开销,这可能会牺牲计时器的准确性,因此CYCLE最好使用计时器。

    语句(或阶段)执行所需的时间通常比执行一次等待所需的时间大几个数量级。对于时间陈述,最重要的标准是要有一个精确的度量,不受处理器频率变化的影响,因此最好使用不基于周期的定时器。语句的默认计时器为NANOSECOND。与之相比,额外的“开销”CYCLE计时器并不重要,因为与执行语句本身所用的CPU时间相比,两次调用计时器(语句开始时一次,语句结束时一次)引起的开销要小几个数量级。使用CYCLE计时器在这里没有好处,只有缺点。

    周期计数器提供的精度取决于处理器速度。如果处理器以1 GHz(十亿个周期/秒)或更高的频率运行,则周期计数器可提供亚纳秒级的精度。使用周期计数器比获取一天中的实际时间便宜得多。例如,标准gettimeofday()功能可能要花费数百个周期,这对于每秒可能发生数千或数百万次的数据收集来说是不可接受的开销。

    周期计数器也有缺点:

    • 最终用户希望以壁钟为单位参见计时,例如几分之一秒。从周期转换为几分之一秒可能会很昂贵。因此,转换是一种快速且相当粗略的乘法运算。
    • 处理器周期率可能会发生变化,例如当注意本电脑进入节能模式时或当CPU速度降低以减少热量产生时。如果处理器的周期速率波动,则从周期到实时单位的转换会出错。
    • 周期计数器可能不可靠或不可用,具体取决于处理器或操作系统。例如,在奔腾上,该指令是RDTSC(汇编语言而不是C指令),并且从理论上讲,操作系统有可能阻止用户模式程序使用它。
    • 与乱序执行或多处理器同步有关的某些处理器详细信息可能会使计数器看起来快或慢达1000个周期。

    MySQL在x386(Windows,macOS,Linux,Solaris和其他Unix版本),PowerPC和IA-64上使用周期计数器。

    事件中的性能架构计时器表示

    行中存储时事和历史事件有三列表示定时信息的性能架构表:TIMER_STARTTIMER_END指示当事件开始和结束,并TIMER_WAIT表示事件持续时间。

    setup_instruments表具有一ENABLED列以指示要为其收集事件的工具。该表还具有一TIMED列以指示要计时的仪器。如果未启用仪器,则不会产生任何事件。如果启用了仪器不能定时,通过仪器产生的事件都NULLTIMER_STARTTIMER_ENDTIMER_WAIT定时器的值。反过来,这会导致在汇总表中计算合计时间值(总和,最小值,最大值和平均值)时忽略这些值。

    在内部,事件内的时间以事件计时开始时有效的计时器给定的单位存储。为了从“性能模式”表中检索事件时显示,无论选择了哪个计时器,都以皮秒(万亿分之一秒)为单位显示时间,以将其归一化为标准单位。

    计时器基线(“ time zero ”)发生在服务器启动期间的性能架构初始化时。TIMER_STARTTIMER_END在活动值表示自基线皮秒。TIMER_WAIT值是以皮秒为单位的持续时间。

    事件中的皮秒值是近似值。它们的准确性受与从一个单位转换到另一单位相关的常见误差形式的影响。如果使用了CYCLE计时器并且处理器速率有所变化,则可能会出现偏差。由于这些原因,TIMER_START将事件的值视为自服务器启动以来经过的时间的准确度量是不合理的。另一方面,使用TIMER_START或子句中的TIMER_WAITORDER BY按开始时间或持续时间对事件进行排序是合理的。

    事件中皮秒的选择而不是诸如微秒之类的值具有性能基础。一个实现目标是以统一的时间单位显示结果,而与计时器无关。在理想情况下,该时间单位看起来像壁钟单位,并且相当精确。换句话说,微秒。但是要将周期或纳秒转换为微秒,有必要对每种仪器进行除法。在许多平台上划分都很昂贵。乘法并不昂贵,因此使用了乘法。因此,时间单位是最高可能值的整数倍TIMER_FREQUENCY值,则使用足够大的乘数以确保没有重大的精度损失。结果是时间单位为“皮秒”。”这个精确度假,但决定使开销最小化。

    在执行等待,阶段,语句或事务事件时,相应的当前事件表显示当前事件时序信息:

    events_waits_current
    events_stages_current
    events_statements_current
    events_transactions_current
    

    为了确定尚未完成的事件已经运行了多长时间,计时器列设置如下:

    • TIMER_START被填充。
    • TIMER_END用当前计时器值填充。
    • TIMER_WAIT到目前为止的时间(TIMER_END-TIMER_START)填充。

    尚未完成的事件的END_EVENT_ID值为NULL。要评估到目前为止某个事件所花费的时间,请使用此TIMER_WAIT列。因此,要识别到目前为止尚未完成且花费的时间超过N皮秒的事件,监视应用程序可以在查询中使用此表达式:

    WHERE END_EVENT_ID IS NULL AND TIMER_WAIT > N
    

    如刚才所述的事件识别假设相应的文书ENABLED,并TIMED设置YES和相关消费者被启用。