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