同步翻译平台的修改at 20150531 23:00

感谢瀚高-韩悦悦提交翻译

Author: ChenHuajun

postgresql/doc/src/sgml/pgtesttiming.sgml

@@ -4,12 +4,18 @@
  <refmeta>
   <refentrytitle><application>pg_test_timing</application></refentrytitle>
   <manvolnum>1</manvolnum>
+  <!--
   <refmiscinfo>Application</refmiscinfo>
+  -->
+  <refmiscinfo>应用</refmiscinfo>
  </refmeta>
 
  <refnamediv>
   <refname>pg_test_timing</refname>
+  <!--
   <refpurpose>measure timing overhead</refpurpose>
+  -->
+  <refpurpose>测量时间开销</refpurpose>
  </refnamediv>
 
  <indexterm zone="pgtesttiming">
@@ -24,22 +30,38 @@
  </refsynopsisdiv>
 
  <refsect1>
+  <!--
   <title>Description</title>
+  -->
+  <title>描述</title>
 
- <para>
+<!--
+  <para>
   <application>pg_test_timing</> is a tool to measure the timing overhead
   on your system and confirm that the system time never moves backwards.
   Systems that are slow to collect timing data can give less accurate
   <command>EXPLAIN ANALYZE</command> results.
  </para>
+-->
+ <para>
+  <application>pg_test_timing</>是一个在你的系统上测量时间开销的工具，
+  并确认系统时间从不向后移动。缓慢的收集时间数据的系统会给出较小精度的
+  <command>EXPLAIN ANALYZE</command>结果。
+ </para>
  </refsect1>
 
  <refsect1>
+  <!--
   <title>Options</title>
+  -->
+  <title>选项</title>
 
    <para>
-    <application>pg_test_timing</application> accepts the following
+    <!--
+<application>pg_test_timing</application> accepts the following
     command-line options:
+-->
+<application>pg_test_timing</application>接受下列的命令行选项：
 
     <variablelist>
 
@@ -48,10 +70,14 @@
       <term><option>--duration=<replaceable class="parameter">duration</replaceable></option></term>
       <listitem>
        <para>
-        Specifies the test duration, in seconds. Longer durations
+        <!--
+Specifies the test duration, in seconds. Longer durations
         give slightly better accuracy, and are more likely to discover
         problems with the system clock moving backwards. The default
         test duration is 3 seconds.
+-->
+声明测试持续时间，以秒计。较长的持续时间给出稍微较好的精度，
+并且更有可能发现系统时钟向后移动的问题。缺省的测试持续时间是3秒。
        </para>
       </listitem>
      </varlistentry>
@@ -61,7 +87,10 @@
       <term><option>--version</></term>
       <listitem>
        <para>
-        Print the <application>pg_test_timing</application> version and exit.
+        <!--
+Print the <application>pg_test_timing</application> version and exit.
+-->
+输出<application>pg_test_timing</application>版本并退出。
        </para>
       </listitem>
      </varlistentry>
@@ -71,8 +100,11 @@
       <term><option>--help</></term>
       <listitem>
        <para>
-        Show help about <application>pg_test_timing</application> command line
+        <!--
+Show help about <application>pg_test_timing</application> command line
         arguments, and exit.
+-->
+显示关于<application>pg_test_timing</application>命令行参数的帮助，并退出。
        </para>
       </listitem>
      </varlistentry>
@@ -83,16 +115,26 @@
  </refsect1>
 
  <refsect1>
+  <!--
   <title>Usage</title>
+  -->
+  <title>用法</title>
 
  <refsect2>
+  <!--
   <title>Interpreting results</title>
+  -->
+  <title>解释结果</title>
 
   <para>
-   Good results will show most (>90%) individual timing calls take less than
+<!--
+    Good results will show most (>90%) individual timing calls take less than
    one microsecond. Average per loop overhead will be even lower, below 100
    nanoseconds. This example from an Intel i7-860 system using a TSC clock
    source shows excellent performance:
+-->
+好的结果将显示大多数(>90%)单个时间调用花费不到一微妙。平均每循环开销将更低，
+低于100纳秒。这个示例来自一个Intel i7-860系统，使用TSC时钟资源，显示性能优良：
 
 <screen>
 Testing timing overhead for 3 seconds.
@@ -108,21 +150,33 @@ Histogram of timing durations:
   </para>
 
   <para>
+<!-- 
    Note that different units are used for the per loop time than the
    histogram. The loop can have resolution within a few nanoseconds (nsec),
    while the individual timing calls can only resolve down to one microsecond
    (usec).
+-->
+请注意，每循环时间和直方图使用的时间单位不同。当单个时间调用只能降低到一微妙（usec）解决时，
+该循环可以在几纳秒内解决（nsec）。
   </para>
 
  </refsect2>
  <refsect2>
+  <!--
   <title>Measuring executor timing overhead</title>
+  -->
+  <title>测量执行者时间开销</title>
 
   <para>
+<!-- 
    When the query executor is running a statement using
    <command>EXPLAIN ANALYZE</command>, individual operations are timed as well
    as showing a summary.  The overhead of your system can be checked by
    counting rows with the <application>psql</application> program:
+-->
+当查询执行者使用<command>EXPLAIN ANALYZE</command>运行一个语句时，
+单个操作的时间也可以显示一个总结。你的系统开销可以通过<application>psql</application>
+程序计数行来检查：
 
 <screen>
 CREATE TABLE t AS SELECT * FROM generate_series(1,100000);
@@ -133,24 +187,38 @@ EXPLAIN ANALYZE SELECT COUNT(*) FROM t;
   </para>
 
   <para>
+<!-- 
    The i7-860 system measured runs the count query in 9.8 ms while
    the <command>EXPLAIN ANALYZE</command> version takes 16.6 ms, each
    processing just over 100,000 rows.  That 6.8 ms difference means the timing
    overhead per row is 68 ns, about twice what pg_test_timing estimated it
    would be.  Even that relatively small amount of overhead is making the fully
    timed count statement take almost 70% longer.  On more substantial queries,
    the timing overhead would be less problematic.
+-->
+i7-860系统测量运行计数查询使用了9.8 ms，而<command>EXPLAIN ANALYZE</command>
+版本使用了16.6 ms，每个处理超出100,000行。6.8 ms的差异意味着时间开销每行是68 ns，
+大约是pg_test_timing预估的两倍。即使是相对少量的开销，也使得完整时间计数语句多花费了近70%。
+在更大量的查询上，时间开销将会有更少的问题。
   </para>
 
  </refsect2>
 
  <refsect2>
+  <!--
   <title>Changing time sources</title>
+  -->
+  <title>改变时间来源</title>
   <para>
+<!-- 
    On some newer Linux systems, it's possible to change the clock source used
    to collect timing data at any time.  A second example shows the slowdown
    possible from switching to the slower acpi_pm time source, on the same
    system used for the fast results above:
+-->
+在一些较新的Linux系统上，随时修改用于统计时间数据的时钟来源是可能的。
+第二个例子显示了通过切换到较缓慢acpi_pm时间来源变缓的可能，
+在同一个系统上用于上面快速的结果：
 
 <screen>
 # cat /sys/devices/system/clocksource/clocksource0/available_clocksource
@@ -169,18 +237,27 @@ Histogram of timing durations:
   </para>
 
   <para>
+<!-- 
    In this configuration, the sample <command>EXPLAIN ANALYZE</command> above
    takes 115.9 ms.  That's 1061 nsec of timing overhead, again a small multiple
    of what's measured directly by this utility.  That much timing overhead
    means the actual query itself is only taking a tiny fraction of the
    accounted for time, most of it is being consumed in overhead instead.  In
    this configuration, any <command>EXPLAIN ANALYZE</command> totals involving
    many timed operations would be inflated significantly by timing overhead.
+-->
+在这个配置中，上面的<command>EXPLAIN ANALYZE</command>示例花费了115.9 ms。
+1061纳秒的时间开销，再次是这个工具直接测量的几倍。
+那么多时间开销意味着实际查询本身只花费了其中的一小部分，大多数被消耗掉了。
+在这个配置中，任何<command>EXPLAIN ANALYZE</command>总计都包括许多时间开销显著膨胀的操作。
   </para>
 
   <para>
+<!-- 
    FreeBSD also allows changing the time source on the fly, and it logs
-   information about the timer selected during boot:
+   information about the timer selected during boot: 
+-->
+FreeBSD也允许在运行中修改时间来源，并且它记录在启动时选择的计时器：
 
 <screen>
 # dmesg | grep "Timecounter"
@@ -194,12 +271,18 @@ kern.timecounter.hardware: ACPI-fast -> TSC
   </para>
 
   <para>
+<!-- 
    Other systems may only allow setting the time source on boot.  On older
    Linux systems the "clock" kernel setting is the only way to make this sort
    of change.  And even on some more recent ones, the only option you'll see
    for a clock source is "jiffies".  Jiffies are the older Linux software clock
    implementation, which can have good resolution when it's backed by fast
-   enough timing hardware, as in this example:
+   enough timing hardware, as in this example: 
+-->
+其他系统可能只允许在启动时设置时间来源。在老一些的Linux系统上，
+"clock"内核设置是修改时间来源的唯一方式。即使是在一些最近的系统上，
+你看到的时钟来源的唯一选项是"jiffies"。Jiffies是老一些的Linux软件时钟实现，
+当它依靠在足够快的时间硬件上时，可以有很好的解决，如下面的例子：
 
 <screen>
 $ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
@@ -223,9 +306,13 @@ Histogram of timing durations:
  </refsect2>
 
  <refsect2>
+  <!-- 
   <title>Clock hardware and timing accuracy</title>
+  -->
+  <title>时钟硬件和时间精度</title>
 
   <para>
+<!-- 
    Collecting accurate timing information is normally done on computers using
    hardware clocks with various levels of accuracy.  With some hardware the
    operating systems can pass the system clock time almost directly to
@@ -234,18 +321,31 @@ Histogram of timing durations:
    either case, operating system kernels provide a clock source that hides
    these details.  But the accuracy of that clock source and how quickly it can
    return results varies based on the underlying hardware.
+-->
+收集准确的时间信息通常是在计算机上使用硬件时钟和各种级别的精度来完成的。
+在一些硬件上，操作系统可以传递系统时钟时间直接到程序。
+系统时钟也可以来自一个芯片，简单的提供时间中断，周期性的在一些已知的时间间隔运转。
+在这两种情况下，操作系统内核提供一个时钟资源，隐藏了这些细节。
+但是时钟资源的精度和它可以多快的返回结果基于底层硬件的不同。
   </para>
 
   <para>
+<!-- 
    Inaccurate time keeping can result in system instability.  Test any change
    to the clock source very carefully.  Operating system defaults are sometimes
    made to favor reliability over best accuracy. And if you are using a virtual
    machine, look into the recommended time sources compatible with it.  Virtual
    hardware faces additional difficulties when emulating timers, and there are
    often per operating system settings suggested by vendors.
+-->
+不准确的时间会导致系统不稳定。要小心的测试任何时钟源的改变。
+操作系统默认是有时在支持最好的精度的情况下提供最高的可靠性。如果你正在使用一个虚拟机，
+看看推荐的时间资源兼容。虚拟硬件在计算时间时面临更多的困难，
+通常有供应商建议的每操作系统设置。
   </para>
 
   <para>
+<!-- 
    The Time Stamp Counter (TSC) clock source is the most accurate one available
    on current generation CPUs. It's the preferred way to track the system time
    when it's supported by the operating system and the TSC clock is
@@ -257,49 +357,80 @@ Histogram of timing durations:
    backwards, a problem this program checks for.  And even the newest systems
    can fail to provide accurate TSC timing with very aggressive power saving
    configurations.
+-->
+时间戳计数器(TSC)时钟资源是在当前一代CPU上可用的最精确的一个。
+当操作系统支持它并且TSC时钟可靠时，这是追踪系统时间的首选方式。
+有几种方式，TSC未能提供准确的时间源，使得它不可靠。
+较老的系统可能有一个基于CPU温度变化的TSC时钟，使其无法计时。
+在一些较老的多核CPU上尝试使用TSC会给出与多核不一致的报告时间。
+这会导致时间回退，一个这个程序检查的问题。甚至最新的系统在非常节能的配置下，
+也未能提供准确的TSC时间。
   </para>
 
   <para>
+<!-- 
    Newer operating systems may check for the known TSC problems and switch to a
    slower, more stable clock source when they are seen.  If your system
    supports TSC time but doesn't default to that, it may be disabled for a good
    reason.  And some operating systems may not detect all the possible problems
    correctly, or will allow using TSC even in situations where it's known to be
    inaccurate.
+-->
+较新的操作系统会检查已知的TSC问题，并在观察到问题时切换到一个较缓慢、更稳定的时钟源。
+如果你的系统支持TSC时间，但是缺省不是它，它可能是因为一个好的原因而禁用了。
+一些操作系统可能不能正确的检测所有可能的问题，或者在已知不准确的情况下允许使用TSC。
   </para>
 
   <para>
+<!-- 
    The High Precision Event Timer (HPET) is the preferred timer on systems
    where it's available and TSC is not accurate.  The timer chip itself is
    programmable to allow up to 100 nanosecond resolution, but you may not see
    that much accuracy in your system clock.
+-->
+高精度事件定时器(HPET)在可用并且TSC不准确的系统上是首选的定时器。
+定时器芯片本身是可编程的，允许高达100纳秒的精度，但是你可能在你的系统时钟上没有看到有多精确。
   </para>
 
   <para>
+<!-- 
    Advanced Configuration and Power Interface (ACPI) provides a Power
    Management (PM) Timer, which Linux refers to as the acpi_pm.  The clock
    derived from acpi_pm will at best provide 300 nanosecond resolution.
+-->
+高级配置和电源接口(ACPI)提供了一个电源管理(PM)定时器，Linux称其为acpi_pm。
+该时钟来源于acpi_pm，最高提供300纳秒的精度。
   </para>
 
   <para>
+<!-- 
    Timers used on older PC hardware include the 8254 Programmable Interval
    Timer (PIT), the real-time clock (RTC), the Advanced Programmable Interrupt
    Controller (APIC) timer, and the Cyclone timer.  These timers aim for
    millisecond resolution.
+-->
+较老PC硬件上使用的定时器包括8254可编程间隔计时器(PIT)、实时时钟(RTC)、
+高级可编程中断控制器(APIC)定时器和Cyclone定时器。这些定时器是毫秒精度的。
   </para>
   </refsect2>
  </refsect1>
 
  <refsect1>
+  <!--
   <title>Author</title>
+  -->
+  <title>作者</title>
 
   <para>
    Ants Aasma <email>ants.aasma@eesti.ee</email>
   </para>
  </refsect1>
 
  <refsect1>
+  <!--
   <title>See Also</title>
+  -->
+  <title>又见</title>
 
   <simplelist type="inline">
    <member><xref linkend="sql-explain"></member>