Re: Excessive CPU usage in StandbyReleaseLocks()

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: Excessive CPU usage in StandbyReleaseLocks()
Дата
Msg-id CAEepm=1FnVvVvqcJYYG8BgAhfYpe7obqtoBzHW9Hn7EhVWtCZg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Excessive CPU usage in StandbyReleaseLocks()  (David Rowley <david.rowley@2ndquadrant.com>)
Список pgsql-hackers
Hi David,

On Thu, Jun 21, 2018 at 12:25 AM, David Rowley
<david.rowley@2ndquadrant.com> wrote:
> On 19 June 2018 at 17:43, Thomas Munro <thomas.munro@enterprisedb.com> wrote:
>> The problem is that StandbyReleaseLocks() does a linear search of all
>> known AccessExclusiveLocks when a transaction ends.  Luckily, since
>> v10 (commit 9b013dc2) that is skipped for transactions that haven't
>> taken any AELs and aren't using 2PC, but that doesn't help all users.
>
> Good to see this getting fixed.  My original patch [1] to fix this was
> more along the lines of yours, only I partitioned the List in an array
> indexed by the xid mod size of array.  I had done this as I thought it
> would be faster than a hash table and would likely see the locks
> spread evenly over the table.  IIRC Andres complained and said I
> should use a hashtable, which I see you've done.

Oh!  I hadn't seen that.  I studied 9b013dc2 but it didn't have a link
to your discussion so I didn't know that your original proposal was
completely different to the commit and essentially the same as what
I'm proposing.  I think this is a more fundamental fix to the problem
so I don't understand why it went into the weeds.  I checked if there
was anything I could salvage from your patch but I think HTAB is the
better way to go here.  I will update the commit message to credit you
for the original analysis and point back to your thread.

Looking at your thread, I see that you were also confused about this:

> Although I'm not all
> that sure in which case the function will actually be called with an
> invalid xid.

Anyone?  In my patch I keep that behaviour, but I think it'd be great
to get a comment there to explain why the case is needed.

>> Thoughts?
>
> I do know this is causing quite a bit of trouble out in the wilds. I'd
> be keen to not have to bear the brunt of any more of those troubles,
> but it'll ultimately depend on how risky a patch looks.

Cool.  I'm thinking of pushing this early next week after some more
testing, unless there are objections.  If you have any feedback or
would like to try to poke holes in it, I'd much appreciate it.

-- 
Thomas Munro
http://www.enterprisedb.com


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

Предыдущее
От: Joe Conway
Дата:
Сообщение: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
Следующее
От: Nico Williams
Дата:
Сообщение: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)