From: Achilleas Mantzios <achill@matrix.gatewaynet.com>
To: pgsql-performance@postgresql.org
Subject: Re: pg9.0.3 explain analyze running very slow compared to a different box with much less configuration
Date: Thu, 24 Mar 2011 14:07:29 +0200
Message-ID: <201103241407.29581.achill@matrix.gatewaynet.com> (raw)
In-Reply-To: <AANLkTikecU7M4S-4fmzZqGzs3bgy_yPHj+asKH9vTGEG@mail.gmail.com>
References: <AANLkTinqz7XpmQHr-Utr4GAR1Ld0PKObxdvF+95xtgbW@mail.gmail.com>
<201103241111.03360.achill@matrix.gatewaynet.com>
<AANLkTikecU7M4S-4fmzZqGzs3bgy_yPHj+asKH9vTGEG@mail.gmail.com>
Στις Thursday 24 March 2011 13:39:19 ο/η Marti Raudsepp έγραψε:
> On Thu, Mar 24, 2011 at 11:11, Achilleas Mantzios
> <achill@matrix.gatewaynet.com> wrote:
> > My problem had to do with the speed of gettimeofday. You might want to do some special setting regarding
> > your box's way of reading time for the hw clock.
>
> Just for extra info, on x86, TSC is usually the "fast" timeofday
> implementation. On recent CPUs in single-socket configurations, TSC
> should always be available, regardless of any power management. I
> don't know about multi-socket. If you want to know whether your kernel
> is using tsc, run:
>
That's what i am experiencing as well, in two of my FreeBSD boxes (work/home) i get:
phenom ii X4 :
==========
% sysctl -a | grep -i timecounter
kern.timecounter.tick: 1
kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) i8254(0) dummy(-1000000)
kern.timecounter.hardware: TSC
kern.timecounter.stepwarnings: 0
kern.timecounter.tc.i8254.mask: 65535
kern.timecounter.tc.i8254.counter: 1960
kern.timecounter.tc.i8254.frequency: 1193182
kern.timecounter.tc.i8254.quality: 0
kern.timecounter.tc.ACPI-fast.mask: 4294967295
kern.timecounter.tc.ACPI-fast.counter: 3642319843
kern.timecounter.tc.ACPI-fast.frequency: 3579545
kern.timecounter.tc.ACPI-fast.quality: 1000
kern.timecounter.tc.HPET.mask: 4294967295
kern.timecounter.tc.HPET.counter: 1160619197
kern.timecounter.tc.HPET.frequency: 14318180
kern.timecounter.tc.HPET.quality: 900
kern.timecounter.tc.TSC.mask: 4294967295
kern.timecounter.tc.TSC.counter: 2788277817
kern.timecounter.tc.TSC.frequency: 3400155810
kern.timecounter.tc.TSC.quality: -100
kern.timecounter.smp_tsc: 0
kern.timecounter.invariant_tsc: 1
Pentium 4
======
% sysctl -a | grep -i timecounter
kern.timecounter.tick: 1
kern.timecounter.choice: TSC(800) ACPI-fast(1000) i8254(0) dummy(-1000000)
kern.timecounter.hardware: ACPI-fast
kern.timecounter.stepwarnings: 0
kern.timecounter.tc.i8254.mask: 65535
kern.timecounter.tc.i8254.counter: 13682
kern.timecounter.tc.i8254.frequency: 1193182
kern.timecounter.tc.i8254.quality: 0
kern.timecounter.tc.ACPI-fast.mask: 16777215
kern.timecounter.tc.ACPI-fast.counter: 6708142
kern.timecounter.tc.ACPI-fast.frequency: 3579545
kern.timecounter.tc.ACPI-fast.quality: 1000
kern.timecounter.tc.TSC.mask: 4294967295
kern.timecounter.tc.TSC.counter: 3109326068
kern.timecounter.tc.TSC.frequency: 2663194296
kern.timecounter.tc.TSC.quality: 800
kern.timecounter.smp_tsc: 0
kern.timecounter.invariant_tsc: 0
TSC, it seems, outperform the rest of clocks in terms of frequency.
> cat /sys/devices/system/clocksource/clocksource0/current_clocksource
>
> On older CPUs, you often had to disable some sort of power management
> in order to get a stable TSC -- the "ondemand" scaling governor is the
> top suspect. Disabling this is distro-specific. You have to reboot to
> get the kernel to re-test TSC. Unfortunately disabling power
> management later at boot doesn't help you, you have to prevent it from
> activating at all.
>
> For debugging, grepping dmesg for tsc or clocksource is often helpful.
> On machines with unstable TSC you'll see output like this:
>
> [ 0.000000] Fast TSC calibration using PIT
> [ 0.164068] checking TSC synchronization [CPU#0 -> CPU#1]: passed.
> [ 0.196730] Switching to clocksource tsc
> [ 0.261347] Marking TSC unstable due to TSC halts in idle
> [ 0.261536] Switching to clocksource acpi_pm
>
> If you just want to get repeatable timings, you can force both
> machines to use the hpet clocksource:
> echo hpet > /sys/devices/system/clocksource/clocksource0/current_clocksource
>
> Marti
>
--
Achilleas Mantzios
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: achill@matrix.gatewaynet.com
Subject: Re: pg9.0.3 explain analyze running very slow compared to a different box with much less configuration
In-Reply-To: <201103241407.29581.achill@matrix.gatewaynet.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox