Re: lwlock:LockManager wait_events

From: Sean Massey <sean(dot)f(dot)massey(at)gmail(dot)com>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Cc: James Pang <jamespang886(at)gmail(dot)com>, pgsql-performance(at)lists(dot)postgresql(dot)org
Subject: Re: lwlock:LockManager wait_events
Date: 2024-10-25 08:37:25
Message-ID: CAJfn5C0yBVsuoQR+RoVjHeK3Vp7x=KouhYAtVAdbM3Fm+we1qQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

You may find this helpful, the advice is not specific to RDS.

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/wait-event.lw-lock-manager.html

HTH.

On Fri, 25 Oct 2024 at 18:36, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> wrote:

> On Fri, 2024-10-25 at 14:36 +0800, James Pang wrote:
> > we faced into a lot of lwlock:LockManager wait-events , all of these
> queries are "select ..." ,
> > there are other several session are doing DML, insert/update/delete on
> same table.
> > Did these DML transactions holding "transactionid" and "tuple" lock
> blocking "select" on lwlock:LockManager ?
>
> This is not about waiting for a lock. Rather, it means that very many
> sessions are trying
> to take a lock. They have to grab the lock manager to take a lock, and
> the competition for
> that resource is the bottleneck.
>
> It is hard to say what is the root cause without further analysis, but
> very often the
> cause is that you have too many connections to the database. Using an
> effective connection
> pool *might* solve that particular problem.
>
> Yours,
> Laurenz Albe
>
>
>

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Ba Jinsheng 2024-10-25 09:26:17 Re: Unexpected Performance for the Function simplify_function
Previous Message James Pang 2024-10-25 07:59:26 Re: proposal: schema variables