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