2.12.?ux_test_timing

2.12.1. 用法
2.12.2. 描述
2.12.3. 选项
2.12.4. 功能

ux_test_timing — 度量计时开销

2.12.1.?用法

ux_test_timing [option...]

2.12.2.?描述

ux_test_timing是一种度量在你的系统上计时开销以及确认系统时间绝不会回退的工具。收集计时数据很慢的系统会给出不太准确的EXPLAIN ANALYZE结果。

2.12.3.?选项

ux_test_timing接受下列命令行选项:

-d duration
--duration=duration

指定测试的持续时间,以秒计。更长的持续时间会给出更好一些的精确度,并且更可能发现系统时钟回退的问题。默认的测试持续时间是3秒。

-V
--version

打印ux_test_timing版本并退出。

-?
--help

显示有关ux_test_timing的命令行参数,然后退出。

2.12.4.?功能

2.12.4.1.?结果解读

好的结果将显示大部分(>90%)的单个计时调用用时都小于1微秒。每次循环的平均开销将会更低,低于100纳秒。下面的例子来自于一台使用了一份TSC时钟源码的Intel i7-860系统,它展示了非常好的性能:

Testing timing overhead for 3 seconds.
Per loop time including overhead: 35.96 ns
Histogram of timing durations:
  < us   % of total      count
     1     96.40465   80435604 
     2      3.59518    2999652  
     4      0.00015        126  
     8      0.00002         13  
    16      0.00000          2  

注意每次循环时间和柱状图用的单位是不同的。循环的解析度可以在几个纳秒(ns),而单个计时调用只能解析到一个微秒(us)。

2.12.4.2.?度量执行器计时开销

当查询执行器使用EXPLAIN ANALYZE运行一个语句时,单个操作会被计时,总结也会被显示。你的系统的负荷可以通过使用uxsql程序计数行来检查:

CREATE TABLE t AS SELECT * FROM generate_series(1,100000);
\timing
SELECT COUNT(*) FROM t;
EXPLAIN ANALYZE SELECT COUNT(*) FROM t;

i7-860系统测到运行该计数查询用了9.8 ms而EXPLAIN ANALYZE版本则需要16.6ms,每次处理都在100,000行上进行。6.8 ms的差别意味着在每行上的计时负荷是68 ns,大概是 ux_test_timing 估计的两倍。即使这样相对少量的负荷也造成了带有计时的计数语句耗时多出了70%。在更大量的查询上,计时开销带来的问题不会有这么明显。

2.12.4.3.?改变时间来源

在一些较新的 Linux 系统上,可以在任何时候更改用来收集计时数据的时钟来源。第二个例子显示了在上述快速结果的相同系统上切换到较慢的acpi_pm时间源可能带来的降速:

# cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm
# echo acpi_pm > /sys/devices/system/clocksource/clocksource0/current_clocksource
# ux_test_timing
Per loop time including overhead: 722.92 ns
Histogram of timing durations:
  < us   % of total      count
     1     27.84870    1155682 
     2     72.05956    2990371 
     4      0.07810       3241  
     8      0.01357        563  
    16      0.00007          3  

在这种配置中,上面的例子EXPLAIN ANALYZE用了115.9 ms。其中有1061 ns的计时开销,还是用这个工具直接度量结果的一个小倍数。这么多的计时开销意味着实际的查询本身只占了时间的一个很小的分数,大部分的时间都耗在了计时所需的管理开销上。在这种配置中,任何涉及到很多计时操作的EXPLAIN ANALYZE都会受到计时开销的显著影响。

在旧的 Linux 系统上,“clock”内核设置是做这类更改的唯一方法。并且即使在一些更近的系统上,对于一个时钟源你将只能看到唯一的选项 "jiffies"。Jiffies 是老的 Linux 软件时钟实现,当有足够快的计时硬件支持时,它能够具有很好的解析度,就像在这个例子中:

$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
jiffies
$ dmesg | grep time.c
time.c: Using 3.579545 MHz WALL PM GTOD PIT/TSC timer.
time.c: Detected 2400.153 MHz processor.
$ ux_test_timing
Testing timing overhead for 3 seconds.
Per timing duration including loop overhead: 97.75 ns
Histogram of timing durations:
  < us   % of total      count
     1     90.23734   27694571 
     2      9.75277    2993204  
     4      0.00981       3010  
     8      0.00007         22  
    16      0.00000          1  
    32      0.00000          1  

2.12.4.4.?时钟硬件和计时准确性

在计算机上通常是使用具有不同精度的时钟硬件收集准确的计时信息。操作系统基本能够通过使用一些硬件直接把系统时钟时间传递给程序。系统时钟也可以产生于一块简单的芯片,这块芯片提供计时中断、在某个已知时间间隔内周期性地发出滴答声。在两种情况中,操作系统内核提供一个隐藏这些细节的时钟源。但是时钟源的精确度以及能多快返回结果会根据底层硬件而变化。

不精确的计时导致系统不稳定,对任何时钟源的更改都要仔细地测试。操作系统默认是有时会更倾向于可靠性而不是精确性。如果正在使用一个虚拟机器,应查看与之兼容的推荐时间源。在模拟计时器时,虚拟硬件面临着额外的困难,供应商通常会建议对每个操作系统进行设置。

时间戳计数器(TSC)时钟源是当前一代CPU上最精确的一种。当操作系统支持TSC并且TSC可靠时,它是跟踪系统时间更好的方式。有多种方式会使TSC无法提供准确的计时源,这会让它不可靠。旧的系统能有一种基于CPU温度变化的TSC时钟,这让它不能用于计时。尝试在一些就的多核CPU上使用TSC可能在多个核心之间给出不一致的时间报告。这可能导致时间倒退,这个程序会检查这种问题。并且即使最新的系统,在非常激进的节能配置下也可能无法提供准确的TSC计时。

更新的操作系统可能检查已知的TSC问题并且当它们被发现时切换到一种更慢、更稳定的时钟源。如果你的系统支持TSC时间但是并不默认使用它,很可能是由于某种充分的理由才禁用它。某些操作系统可能无法正确地检测所有可能的问题,或者即便在知道TSC不精确的情况下也允许使用TSC。

如果系统上有高精度事件计时器(HPET)并且TSC不准确,该系统将会更喜欢HPET计时器。计时器芯片本身是可编程的,最高允许100纳米的解析度,但是在你的系统时钟中可能见不到那么高的准确度。

高级配置和电源接口(ACPI)提供了一种电源管理(PM)计时器,Linux 把它称之为acpi_pm。得自于acpi_pm 的时钟最好时将能提供300纳秒的解析度。

在旧的PC硬件上使用的计时器包括8254可编程区间计时器(PIT)、实时时钟(RTC)、高级可编程中断控制器(APIC)计时器以及Cyclone计时器。这些计时器是以毫秒解析度为目标的。

XML 地图 | Sitemap 地图