Re: Quantify small changes to predicate evaluation
От | Marti Raudsepp |
---|---|
Тема | Re: Quantify small changes to predicate evaluation |
Дата | |
Msg-id | CABRT9RAp_ONHG-VF7fkQiezq-q6=xp1TMYJYSsKCjzDda=WfnA@mail.gmail.com обсуждение исходный текст |
Ответ на | Quantify small changes to predicate evaluation (Dennis Butterstein <soullinuxer@web.de>) |
Ответы |
Re: Quantify small changes to predicate evaluation
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: