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