Re: Performance degradation in commit 6150a1b0

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Performance degradation in commit 6150a1b0
Дата
Msg-id CANP8+jLmxbqTFeOBKgjgPF7DXc6qJKV9hYii+L10xSrsVrVG2w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Performance degradation in commit 6150a1b0  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: Performance degradation in commit 6150a1b0  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 25 February 2016 at 18:42, Amit Kapila <amit.kapila16@gmail.com> wrote:
On Thu, Feb 25, 2016 at 11:38 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
On 24 February 2016 at 23:26, Amit Kapila <amit.kapila16@gmail.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.

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/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Konstantin Knizhnik
Дата:
Сообщение: Re: Relation cache invalidation on replica
Следующее
От: Valery Popov
Дата:
Сообщение: Re: Password identifiers, protocol aging and SCRAM protocol