Re: [HACKERS] 9.4 -> 9.5 regression with queries through pgbouncer on RHEL 6

From: Vladimir Borodin <root(at)simply(dot)name>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-performance(at)postgresql(dot)org, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] 9.4 -> 9.5 regression with queries through pgbouncer on RHEL 6
Date: 2016-07-04 13:30:51
Message-ID: E8E521D6-0457-4A85-B085-59B8BA40AD2D@simply.name
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance


> 13 июня 2016 г., в 21:58, Vladimir Borodin <root(at)simply(dot)name> написал(а):
>
>>
>> 13 июня 2016 г., в 0:51, Andres Freund <andres(at)anarazel(dot)de <mailto:andres(at)anarazel(dot)de>> написал(а):
>>
>> Hi Vladimir,
>>
>> Thanks for these reports.
>>
>> On 2016-06-13 00:42:19 +0300, Vladimir Borodin wrote:
>>> perf report -g -i pg9?_all.data >/tmp/pg9?_perf_report.txt
>>
>> Any chance you could redo the reports with --no-children --call-graph=fractal
>> added? The mode that includes child overheads unfortunately makes the
>> output hard to interpet/compare.
>
> Of course. Not sure if that is important but I upgraded perf for that (because --no-children option was introduced in ~3.16), so perf record and perf report were done with different perf versions.
>
> <pg94_perf_report.txt.gz>
> <pg95_perf_report.txt.gz>
> <pg96_perf_report.txt.gz>
>
> Also I’ve done the same test on same host (RHEL 6) but with 4.6 kernel/perf and writing perf data to /dev/shm for not loosing events. Perf report output is also attached but important thing is that the regression is not so significant:
>
> root(at)pgload05g ~ # uname -r
> 4.6.0-1.el6.elrepo.x86_64
> root(at)pgload05g ~ # cat /proc/sys/kernel/sched_autogroup_enabled
> 1
> root(at)pgload05g ~ # /tmp/run.sh
> RHEL 6 9.4 71634 0.893
> RHEL 6 9.5 54005 1.185
> RHEL 6 9.6 65550 0.976
> root(at)pgload05g ~ # echo 0 >/proc/sys/kernel/sched_autogroup_enabled
> root(at)pgload05g ~ # /tmp/run.sh
> RHEL 6 9.4 73041 0.876
> RHEL 6 9.5 60105 1.065
> RHEL 6 9.6 67984 0.941
> root(at)pgload05g ~ #
>
> <pg96_perf_report_4.6.txt.gz>
> <pg95_perf_report_4.6.txt.gz>
> <pg94_perf_report_4.6.txt.gz>

Andres, is there any chance that you would find time to look at those results? Are they actually useful?

>
>
>>
>>> The results from pg9?_perf_report.txt are attached. Note that in all cases some events were lost, i.e.:
>>>
>>> root(at)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!
>>
>> You can reduce the overhead by reducing the sampling frequency, e.g. by
>> specifying -F 300.
>>
>> Greetings,
>>
>> Andres Freund
>>
>>
>> --
>> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org <mailto:pgsql-hackers(at)postgresql(dot)org>)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-hackers <http://www.postgresql.org/mailpref/pgsql-hackers>
>
>
> --
> May the force be with you…
> https://simply.name <https://simply.name/>

--
May the force be with you…
https://simply.name

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2016-07-04 13:58:51 Re: Re: GiST optimizing memmoves in gistplacetopage for fixed-size updates [PoC]
Previous Message Victor Giannakouris - Salalidis 2016-07-04 13:10:26 Re: Statistics Injection

Browse pgsql-performance by date

  From Date Subject
Next Message Kouber Saparev 2016-07-04 16:35:47 DELETE takes too much memory
Previous Message devel.brain99 2016-07-04 12:19:08 Re: Random slow queries