Thread: Re: [PERFORM] 9.4 -> 9.5 regression with queries through pgbouncer on RHEL 6
Re: [PERFORM] 9.4 -> 9.5 regression with queries through pgbouncer on RHEL 6
From
Vladimir Borodin
Date:
10 июня 2016 г., в 1:28, Andres Freund <andres@anarazel.de> написал(а):Hi,
On 2016-06-02 14:18:26 +0300, Антон Бушмелев wrote:UP. repeat tests on local vm.. reults are discouraging
OS PG TPS AVG latency
Centos 7 9.5.3 23.711023 168.421
Centos 7 9.5.3 26.609271 150.188
Centos 7 9.5.3 25.220044 158.416
Centos 7 9.5.3 25.598977 156.047
Centos 7 9.4.8 278.572191 14.077
Centos 7 9.4.8 247.237755 16.177
Centos 7 9.4.8 240.007524 16.276
Centos 7 9.4.8 237.862238 16.596
Could you provide profiles on 9.4 and 9.5? Which kernel did you have
enabled? Is /proc/sys/kernel/sched_autogroup_enabled 1 or 0?
I don’t know anything about Anton’s installation. I’m having troubles on RHEL 6 with stock kernel (2.6.32-642.el6.x86_64). I also tried a couple of non-official kernels (3.10, 3.19) but results didn’t change much.
/proc/sys/kernel/sched_autogroup_enabled doesn’t change the picture in general for 9.5 or 9.6 but improves for 9.4:
root@pgload05g ~ # cat /proc/sys/kernel/sched_autogroup_enabled
0
root@pgload05g ~ # /tmp/run.sh
RHEL 6 9.4 69163 0.925
RHEL 6 9.5 34495 1.855
RHEL 6 9.6 70631 0.906
root@pgload05g ~ # echo 1 >/proc/sys/kernel/sched_autogroup_enabled
root@pgload05g ~ # /tmp/run.sh
RHEL 6 9.4 82242 0.778
RHEL 6 9.5 34100 1.877
RHEL 6 9.6 70599 0.907
root@pgload05g ~ #
For taking perf profiles I’ve recompiled all versions with CFLAGS='-O2 -fno-omit-frame-pointer’ and issued the following command during pgbench runs:
perf record -g --call-graph=dwarf -a -o pg9?_all.data sleep 10
After run:
perf report -g -i pg9?_all.data >/tmp/pg9?_perf_report.txt
The results from pg9?_perf_report.txt are attached. Note that in all cases some events were lost, i.e.:
root@pgload05g ~ # perf report -g -i pg94_all.data >/tmp/pg94_perf_report.txt
Failed to open [vsyscall], continuing without symbols
Warning:
Processed 537137 events and lost 7846 chunks!
Check IO/CPU overload!
root@pgload05g ~ #
The reason for that is overloaded I/O subsystem.
Regards,
Andres