Re: Performance degradation in commit 6150a1b0

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

On 25 February 2016 at 18:42, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:

> 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
>

Don't understand this. If a problem is caused by one of two things, first
you check one, then the other.

--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Valery Popov 2016-02-26 15:16:55 Re: Password identifiers, protocol aging and SCRAM protocol
Previous Message Konstantin Knizhnik 2016-02-26 15:05:55 Re: Relation cache invalidation on replica