# 皮克_测试_定时

皮克_测试_计时 — 测量计时开销

# 概要

pg_test_timing [选项...]

# 描述

皮克_测试_计时是一种测量系统计时开销并确认系统时间永不倒退的工具。收集计时数据较慢的系统可能会降低准确性解释分析结果。

# 选项

皮克_测试_计时接受以下命令行选项:

-d *期间*
--持续时间=*期间*

指定测试持续时间,以秒为单位。较长的持续时间会提供更好的准确性,并且更有可能发现系统时钟向后移动的问题。默认测试持续时间为 3 秒。

-V
- 版本

打印 pg_测试_计时版本并退出。

-?
- 帮助

显示关于 pg 的帮助_测试_计时命令行参数,然后退出。

# 用法

# 解释结果

好的结果将显示大多数 (>90%) 单独的计时调用不到一微秒。每个循环的平均开销会更低,低于 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)。

# 测量执行器时序开销

当查询执行器运行语句时使用解释分析,个别操作是定时的以及显示一个摘要。可以通过使用 psql 程序计算行数来检查系统的开销:

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 毫秒内运行计数查询,而解释分析版本需要 16.6 毫秒,每个处理超过 100,000 行。6.8 ms 的差异意味着每行的时序开销为 68 ns,大约是 pg 的两倍_测试_时间估计会。即使是相对较少的开销,也使得完全定时的计数语句花费了近 70% 的时间。在更实质性的查询中,时间开销问题会更小。

# 改变时间源

在一些较新的 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
# pg_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

在此配置中,示例解释分析以上需要 115.9 毫秒。这是 1061 ns 的时序开销,也是该实用程序直接测量的小倍数。这么多的时间开销意味着实际查询本身只占用了计算时间的一小部分,其中大部分时间都消耗在开销上。在这种配置中,任何解释分析涉及许多定时操作的总数会因定时开销而显着增加。

FreeBSD 还允许动态更改时间源,并记录有关在启动期间选择的计时器的信息:

# dmesg | grep "Timecounter"
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounters tick every 10.000 msec
Timecounter "TSC" frequency 2531787134 Hz quality 800
# sysctl kern.timecounter.hardware=TSC
kern.timecounter.hardware: ACPI-fast -> TSC

其他系统可能只允许在启动时设置时间源。在较旧的 Linux 系统上,“时钟”内核设置是进行此类更改的唯一方法。即使在一些较新的版本中,您会看到的时钟源的唯一选项是“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.
$ pg_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

# 时钟硬件和时序精度

收集准确的计时信息通常是在计算机上使用具有不同精度级别的硬件时钟来完成的。对于某些硬件,操作系统几乎可以将系统时钟时间直接传递给程序。系统时钟也可以从简单地提供定时中断、在某个已知时间间隔的周期性滴答声的芯片中获得。在任何一种情况下,操作系统内核都提供了一个隐藏这些细节的时钟源。但是该时钟源的准确性以及它返回结果的速度会因底层硬件而异。

时间保持不准确会导致系统不稳定。非常仔细地测试对时钟源的任何更改。有时,操作系统默认设置是为了支持可靠性而不是最佳准确性。如果您使用的是虚拟机,请查看与其兼容的推荐时间源。虚拟硬件在模拟计时器时面临额外的困难,并且供应商通常会建议每个操作系统的设置。

时间戳计数器 (TSC) 时钟源是当前一代 CPU 上可用的最准确的时钟源。当操作系统支持且 TSC 时钟可靠时,它是跟踪系统时间的首选方式。TSC 有多种方式无法提供准确的时序源,从而使其不可靠。较旧的系统可能具有根据 CPU 温度变化的 TSC 时钟,因此无法用于计时。尝试在一些较旧的多核 CPU 上使用 TSC 可能会报告多核之间不一致的时间。这可能导致时间倒退,这是该程序检查的问题。即使是最新的系统也可能无法通过非常激进的节能配置提供准确的 TSC 时序。

较新的操作系统可能会检查已知的 TSC 问题,并在发现这些问题时切换到更慢、更稳定的时钟源。如果您的系统支持 TSC 时间但没有默认设置,那么它可能被禁用是有充分理由的。并且某些操作系统可能无法正确检测所有可能的问题,或者即使在已知不准确的情况下也允许使用 TSC。

高精度事件计时器 (HPET) 是可用且 TSC 不准确的系统上的首选计时器。定时器芯片本身是可编程的,允许高达 100 纳秒的分辨率,但您可能看不到系统时钟的准确度。

高级配置和电源接口 (ACPI) 提供了电源管理 (PM) 计时器,Linux 将其称为 acpi_下午。来自acpi的时钟_pm 最多只能提供 300 纳秒的分辨率。

旧 PC 硬件上使用的定时器包括 8254 可编程间隔定时器 (PIT)、实时时钟 (RTC)、高级可编程中断控制器 (APIC) 定时器和 Cyclone 定时器。这些计时器的目标是毫秒分辨率。

# 也可以看看

解释