On Fri, Jun 13, 2014 at 12:46 PM, Dennis Butterstein <soullinuxer@web.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
