begriffs open source - ai-pg/blob - full-docs/txt/pgtesttiming.txt

   1
   2 pg_test_timing
   3
   4    pg_test_timing — measure timing overhead
   5
   6 Synopsis
   7
   8    pg_test_timing [option...]
   9
  10 Description
  11
  12    pg_test_timing is a tool to measure the timing overhead on your system
  13    and confirm that the system time never moves backwards. Systems that
  14    are slow to collect timing data can give less accurate EXPLAIN ANALYZE
  15    results.
  16
  17 Options
  18
  19    pg_test_timing accepts the following command-line options:
  20
  21    -d duration
  22           --duration=duration
  23           Specifies the test duration, in seconds. Longer durations give
  24           slightly better accuracy, and are more likely to discover
  25           problems with the system clock moving backwards. The default
  26           test duration is 3 seconds.
  27
  28    -V
  29           --version
  30           Print the pg_test_timing version and exit.
  31
  32    -?
  33           --help
  34           Show help about pg_test_timing command line arguments, and exit.
  35
  36 Usage
  37
  38 Interpreting Results
  39
  40    Good results will show most (>90%) individual timing calls take less
  41    than one microsecond. Average per loop overhead will be even lower,
  42    below 100 nanoseconds. This example from an Intel i7-860 system using a
  43    TSC clock source shows excellent performance:
  44 Testing timing overhead for 3 seconds.
  45 Per loop time including overhead: 35.96 ns
  46 Histogram of timing durations:
  47   < us   % of total      count
  48      1     96.40465   80435604
  49      2      3.59518    2999652
  50      4      0.00015        126
  51      8      0.00002         13
  52     16      0.00000          2
  53
  54    Note that different units are used for the per loop time than the
  55    histogram. The loop can have resolution within a few nanoseconds (ns),
  56    while the individual timing calls can only resolve down to one
  57    microsecond (us).
  58
  59 Measuring Executor Timing Overhead
  60
  61    When the query executor is running a statement using EXPLAIN ANALYZE,
  62    individual operations are timed as well as showing a summary. The
  63    overhead of your system can be checked by counting rows with the psql
  64    program:
  65 CREATE TABLE t AS SELECT * FROM generate_series(1,100000);
  66 \timing
  67 SELECT COUNT(*) FROM t;
  68 EXPLAIN ANALYZE SELECT COUNT(*) FROM t;
  69
  70    The i7-860 system measured runs the count query in 9.8 ms while the
  71    EXPLAIN ANALYZE version takes 16.6 ms, each processing just over
  72    100,000 rows. That 6.8 ms difference means the timing overhead per row
  73    is 68 ns, about twice what pg_test_timing estimated it would be. Even
  74    that relatively small amount of overhead is making the fully timed
  75    count statement take almost 70% longer. On more substantial queries,
  76    the timing overhead would be less problematic.
  77
  78 Changing Time Sources
  79
  80    On some newer Linux systems, it's possible to change the clock source
  81    used to collect timing data at any time. A second example shows the
  82    slowdown possible from switching to the slower acpi_pm time source, on
  83    the same system used for the fast results above:
  84 # cat /sys/devices/system/clocksource/clocksource0/available_clocksource
  85 tsc hpet acpi_pm
  86 # echo acpi_pm > /sys/devices/system/clocksource/clocksource0/current_clocksourc
  87 e
  88 # pg_test_timing
  89 Per loop time including overhead: 722.92 ns
  90 Histogram of timing durations:
  91   < us   % of total      count
  92      1     27.84870    1155682
  93      2     72.05956    2990371
  94      4      0.07810       3241
  95      8      0.01357        563
  96     16      0.00007          3
  97
  98    In this configuration, the sample EXPLAIN ANALYZE above takes 115.9 ms.
  99    That's 1061 ns of timing overhead, again a small multiple of what's
 100    measured directly by this utility. That much timing overhead means the
 101    actual query itself is only taking a tiny fraction of the accounted for
 102    time, most of it is being consumed in overhead instead. In this
 103    configuration, any EXPLAIN ANALYZE totals involving many timed
 104    operations would be inflated significantly by timing overhead.
 105
 106    FreeBSD also allows changing the time source on the fly, and it logs
 107    information about the timer selected during boot:
 108 # dmesg | grep "Timecounter"
 109 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
 110 Timecounter "i8254" frequency 1193182 Hz quality 0
 111 Timecounters tick every 10.000 msec
 112 Timecounter "TSC" frequency 2531787134 Hz quality 800
 113 # sysctl kern.timecounter.hardware=TSC
 114 kern.timecounter.hardware: ACPI-fast -> TSC
 115
 116    Other systems may only allow setting the time source on boot. On older
 117    Linux systems the "clock" kernel setting is the only way to make this
 118    sort of change. And even on some more recent ones, the only option
 119    you'll see for a clock source is "jiffies". Jiffies are the older Linux
 120    software clock implementation, which can have good resolution when it's
 121    backed by fast enough timing hardware, as in this example:
 122 $ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
 123 jiffies
 124 $ dmesg | grep time.c
 125 time.c: Using 3.579545 MHz WALL PM GTOD PIT/TSC timer.
 126 time.c: Detected 2400.153 MHz processor.
 127 $ pg_test_timing
 128 Testing timing overhead for 3 seconds.
 129 Per timing duration including loop overhead: 97.75 ns
 130 Histogram of timing durations:
 131   < us   % of total      count
 132      1     90.23734   27694571
 133      2      9.75277    2993204
 134      4      0.00981       3010
 135      8      0.00007         22
 136     16      0.00000          1
 137     32      0.00000          1
 138
 139 Clock Hardware and Timing Accuracy
 140
 141    Collecting accurate timing information is normally done on computers
 142    using hardware clocks with various levels of accuracy. With some
 143    hardware the operating systems can pass the system clock time almost
 144    directly to programs. A system clock can also be derived from a chip
 145    that simply provides timing interrupts, periodic ticks at some known
 146    time interval. In either case, operating system kernels provide a clock
 147    source that hides these details. But the accuracy of that clock source
 148    and how quickly it can return results varies based on the underlying
 149    hardware.
 150
 151    Inaccurate time keeping can result in system instability. Test any
 152    change to the clock source very carefully. Operating system defaults
 153    are sometimes made to favor reliability over best accuracy. And if you
 154    are using a virtual machine, look into the recommended time sources
 155    compatible with it. Virtual hardware faces additional difficulties when
 156    emulating timers, and there are often per operating system settings
 157    suggested by vendors.
 158
 159    The Time Stamp Counter (TSC) clock source is the most accurate one
 160    available on current generation CPUs. It's the preferred way to track
 161    the system time when it's supported by the operating system and the TSC
 162    clock is reliable. There are several ways that TSC can fail to provide
 163    an accurate timing source, making it unreliable. Older systems can have
 164    a TSC clock that varies based on the CPU temperature, making it
 165    unusable for timing. Trying to use TSC on some older multicore CPUs can
 166    give a reported time that's inconsistent among multiple cores. This can
 167    result in the time going backwards, a problem this program checks for.
 168    And even the newest systems can fail to provide accurate TSC timing
 169    with very aggressive power saving configurations.
 170
 171    Newer operating systems may check for the known TSC problems and switch
 172    to a slower, more stable clock source when they are seen. If your
 173    system supports TSC time but doesn't default to that, it may be
 174    disabled for a good reason. And some operating systems may not detect
 175    all the possible problems correctly, or will allow using TSC even in
 176    situations where it's known to be inaccurate.
 177
 178    The High Precision Event Timer (HPET) is the preferred timer on systems
 179    where it's available and TSC is not accurate. The timer chip itself is
 180    programmable to allow up to 100 nanosecond resolution, but you may not
 181    see that much accuracy in your system clock.
 182
 183    Advanced Configuration and Power Interface (ACPI) provides a Power
 184    Management (PM) Timer, which Linux refers to as the acpi_pm. The clock
 185    derived from acpi_pm will at best provide 300 nanosecond resolution.
 186
 187    Timers used on older PC hardware include the 8254 Programmable Interval
 188    Timer (PIT), the real-time clock (RTC), the Advanced Programmable
 189    Interrupt Controller (APIC) timer, and the Cyclone timer. These timers
 190    aim for millisecond resolution.
 191
 192 See Also
 193
 194    EXPLAIN