From: | Ashkil Dighin <ashkildighin76(at)gmail(dot)com> |
---|---|
To: | Paul Friedman <paul(dot)friedman(at)streetlightdata(dot)com> |
Cc: | MichaelDBA <MichaelDBA(at)sqlexec(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, "pgsql-performance(at)lists(dot)postgresql(dot)org" <pgsql-performance(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Lock contention high |
Date: | 2021-10-14 06:49:21 |
Message-ID: | CAH6zzqDfnC_T4DMnBZPvXOo4A5UWrTOeDNXJiQngwNH=Ju2xGA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Not using PostGIS
On Thursday, October 14, 2021, Paul Friedman <
paul(dot)friedman(at)streetlightdata(dot)com> wrote:
> Are you using PostGIS?
>
> If so, there is an issue with TOAST table locking having these symptoms.
>
>
> ---Paul
>
>
> On Wed, Oct 13, 2021 at 11:15 AM MichaelDBA <MichaelDBA(at)sqlexec(dot)com>
> wrote:
>
>> 1.Is there a way to tune the lock contention ?
>> 2.Is any recommendations to tune/reduce the lock contention via postgres.conf
>>
>> I think you'd want to find *which* LW locks are being waited on, to see if it's
>> something that can be easily tuned.
>>
>> You can check pg_stat_activity, or maybe create a cronjob to record its content
>> for later analysis.
>>
>>
>> Hello,
>>
>> Also turn on log_lock_waits so you can evaluate the actual SQL causing
>> the problems in the PG log files. Thinking ahead, you may want to consider
>> if using advisory locks from the application side of things might be
>> helpful to manage locks in a more pessimistic way. Also, join with
>> pg_locks table to find out the specific resources that are in contention.
>>
>> Regards,
>> Michael Vitale
>>
>>
>>
From | Date | Subject | |
---|---|---|---|
Next Message | Mikhail Zhilin | 2021-10-14 07:47:37 | Re: Lock contention high |
Previous Message | Ashkil Dighin | 2021-10-14 06:45:19 | Re: Lock contention high |