Re: debugging intermittent slow updates under higher load

From: Chris Withers <chris(at)withers(dot)org>
To: Alexey Bashtanov <bashtanov(at)imap(dot)cc>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: debugging intermittent slow updates under higher load
Date: 2018-12-06 08:28:44
Message-ID: df4814c9-b52e-8873-4022-82f7a2476f6c@withers.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 05/12/2018 15:40, Alexey Bashtanov wrote:
>
>>
> One of the reasons could be the row already locked by another backend,
> doing the same kind of an update or something different.
> Are these updates performed in a longer transactions?

Nope, the transaction will just be updating one row at a time.

> Can they hit the same row from two clients at the same time?

I've looked for evidence of this, but can't find any. Certainly nothing
running for 2-10s, queries against this table are normally a few hundred ms.

> Is there any other write or select-for-update/share load on the table?

Not that I'm aware of. How would I go about getting metrics on problems
like these?

> Have you tried periodical logging of the non-granted locks?
> Try querying pg_stat_activity and pg_locks (possibly joined and maybe
> repeatedly self-joined, google for it)
> to get the backends that wait one for another while competing for to
> lock the same row or object.

Is there any existing tooling that does this? I'm loath to start hacking
something up when I'd hope others have done a better job already...

Chris

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Chris Withers 2018-12-06 08:29:49 Re: debugging intermittent slow updates under higher load
Previous Message bhargav kamineni 2018-12-06 07:20:59 order of reading the conf files