Re: Performance degradation in commit 6150a1b0

Hi,

As mentioned in my earlier mail i was not able to apply
*pinunpin-cas-5.patch* on commit *6150a1b0, *therefore i thought of
applying it on the
latest commit and i was able to do it successfully. I have now taken the
performance readings at latest commit i.e. *76281aa9* with and without
applying *pinunpin-cas-5.patch* and my observations are as follows,

1. I can still see that the current performance lags by 2-3% from the
expected performance when *pinunpin-cas-5.patch *is applied on the commit

*76281aa9.*
2. When *pinunpin-cas-5.patch *is ignored and performance is measured at
commit *76281aa9 *the overall performance lags by 50-60% from the expected
performance.

*Note:* Here, the expected performance is the performance observed before
commit *6150a1b0 *when* ac1d794 *is reverted.

Please refer to the attached performance report sheet for more insights.

With Regards,
Ashutosh Sharma
EnterpriseDB: http://www.enterprisedb.com <http://www.enterprisedb.com/>

On Sat, Mar 26, 2016 at 9:31 PM, Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>
wrote:

> Hi,
>
> I am getting some reject files while trying to apply "
> *pinunpin-cas-5.patch*" attached with the thread,
>
>
>
> *http://www.postgresql.org/message-id/CAPpHfdsRoT1JmsnRnCCqpNZEU9vUT7TX6B-N1wyOuWWfhD6F+g@mail.gmail.com
> <http://www.postgresql.org/message-id/CAPpHfdsRoT1JmsnRnCCqpNZEU9vUT7TX6B-N1wyOuWWfhD6F+g@mail.gmail.com>*
> Note: I am applying this patch on top of commit "
> *6150a1b08a9fe7ead2b25240be46dddeae9d98e1*".
>
> With Regards,
> Ashutosh Sharma
> EnterpriseDB: http://www.enterprisedb.com
>
> On Fri, Mar 25, 2016 at 9:29 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
> wrote:
>
>> On Wed, Mar 23, 2016 at 1:59 PM, Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>
>> wrote:
>> >
>> > Hi All,
>> >
>> > I have been working on this issue for last few days trying to
>> investigate what could be the probable reasons for Performance degradation
>> at commit 6150a1b0. After going through Andres patch for moving buffer I/O
>> and content lock out of Main Tranche, the following two things come into my
>> > mind.
>> >
>> > 1. Content Lock is no more used as a pointer in BufferDesc structure
>> instead it is included as LWLock structure. This basically increases the
>> overall structure size from 64bytes to 80 bytes. Just to investigate on
>> this, I have reverted the changes related to content lock from commit
>> 6150a1b0 and taken at least 10 readings and with this change i can see that
>> the overall performance is similar to what it was observed earlier i.e.
>> before commit 6150a1b0.
>> >
>> > 2. Secondly, i can see that the BufferDesc structure padding is 64
>> bytes however the PG CACHE LINE ALIGNMENT is 128 bytes. Also, after
>> changing the BufferDesc structure padding size to 128 bytes along with the
>> changes mentioned in above point #1, I see that the overall performance is
>> again similar to what is observed before commit 6150a1b0.
>> >
>> > Please have a look into the attached test report that contains the
>> performance test results for all the scenarios discussed above and let me
>> know your thoughts.
>> >
>>
>> So this indicates that changing back content lock as LWLock* in
>> BufferDesc brings back the performance which indicates that increase in
>> BufferDesc size to more than 64bytes on this platform has caused
>> regression. I think it is worth trying the patch [1] as suggested by
>> Andres as that will reduce the size of BufferDesc which can bring back the
>> performance. Can you once try the same?
>>
>> [1] -
>> http://www.postgresql.org/message-id/CAPpHfdsRoT1JmsnRnCCqpNZEU9vUT7TX6B-N1wyOuWWfhD6F+g@mail.gmail.com
>>
>> With Regards,
>> Amit Kapila.
>> EnterpriseDB: http://www.enterprisedb.com
>>
>
>