From: | Marti Raudsepp <marti(at)juffo(dot)org> |
---|---|
To: | Dennis Butterstein <soullinuxer(at)web(dot)de> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Quantify small changes to predicate evaluation |
Date: | 2014-06-13 10:12:00 |
Message-ID: | CABRT9RAp_ONHG-VF7fkQiezq-q6=xp1TMYJYSsKCjzDda=WfnA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jun 13, 2014 at 12:46 PM, Dennis Butterstein <soullinuxer(at)web(dot)de> wrote:
> I expect my current changes to be resposible for about 0.2-0.3s for this
> query but because of the huge time differences I am not able to quantify my
> changes.
>
> Maybe somebody can tell me about a better approach to quantify my changes or
> give me some input on how to get more stable postgres time measurements.
There can be other reasons, but for read-only benchmarks, much of this
variability seems to come from the operating system's power management
and scheduler.
I had some luck in reducing variance on Linux with some tricks.
Disable CPU frequency scaling:
for i in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do
echo performance > $i; done
Disable the turbo boost feature if your CPU supports it:
echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo
Always launch PostgreSQL and pgbench on a fixed CPU core, using "taskset -c3"
And exclude all other processes from this core (locking them to cores 0, 1, 2):
ps -A -o pid h |xargs -n1 taskset -cp -a 0-2 >/dev/null
Transparent hugepage support may also interfere:
echo never > /sys/kernel/mm/transparent_hugepage/defrag
echo never > /sys/kernel/mm/transparent_hugepage/enabled
I'm sure there are more tricks, but this should get you pretty far.
Regards,
Marti
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2014-06-13 10:24:19 | Re: Proposal for CSN based snapshots |
Previous Message | Dennis Butterstein | 2014-06-13 09:46:24 | Quantify small changes to predicate evaluation |