Re: Performance degradation in commit 6150a1b0

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Performance degradation in commit 6150a1b0
Date: 2016-02-26 02:42:42
Message-ID: CAA4eK1JdP1+1-V59CsFrf0SBGWD28Ut4ioms5gKEVDq66cnFew@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Feb 25, 2016 at 11:38 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:

> On 24 February 2016 at 23:26, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
>> From past few weeks, we were facing some performance degradation in the
>> read-only performance bench marks in high-end machines. My colleague
>> Mithun, has tried by reverting commit ac1d794 which seems to degrade the
>> performance in HEAD on high-end m/c's as reported previously[1], but still
>> we were getting degradation, then we have done some profiling to see what
>> has caused it and we found that it's mainly caused by spin lock when
>> called via pin/unpin buffer and then we tried by reverting commit 6150a1b0
>> which has recently changed the structures in that area and it turns out
>> that reverting that patch, we don't see any degradation in performance.
>> The important point to note is that the performance degradation doesn't
>> occur every time, but if the tests are repeated twice or thrice, it
>> is easily visible.
>>
>
> Not seen that on the original patch I posted. 6150a1b0 contains multiple
> changes to the lwlock structures, one written by me, others by Andres.
>
> Perhaps we should revert that patch and re-apply the various changes in
> multiple commits so we can see the differences.
>
>
Yes, thats one choice, other is locally we can narrow down the root cause
of problem and then try to address the same. Last time similar issue came
up on list, agreement [1] was to note down it in PostgreSQL 9.6 open items
and then work on it. I think for this problem, we haven't got to the root
cause of problem, so we can try to investigate it. If nobody else steps up
to reproduce and look into problem, in few days, I will look into it.

[1] -
http://www.postgresql.org/message-id/CA+TgmoYjYqegXzrBizL-Ov7zDsS=GavCnxYnGn9WZ1S=rP8DaA@mail.gmail.com

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2016-02-26 02:58:50 Re: [REVIEW] In-core regression tests for replication, cascading, archiving, PITR, etc.
Previous Message Kyotaro HORIGUCHI 2016-02-26 01:53:25 Re: Support for N synchronous standby servers - take 2