Message-ID: <f6065e6cc468acb43df2f0f953ef23a17efffebb.camel@cybertec.at>
Subject: Re: lwlock:LockManager wait_events
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: James Pang <jamespang886@gmail.com>,
	pgsql-performance@lists.postgresql.org
Date: Fri, 25 Oct 2024 10:36:45 +0300
In-Reply-To: 
 <CAHgTRfesRFm1BuG_5guvdSCof2qoHGZvaa1YEkim97EMALaWgQ@mail.gmail.com>
References: 
	<CAHgTRfesRFm1BuG_5guvdSCof2qoHGZvaa1YEkim97EMALaWgQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.52.4 (3.52.4-2.fc40) 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/f6065e6cc468acb43df2f0f953ef23a17efffebb.camel%40cybertec.at>
Precedence: bulk

On Fri, 2024-10-25 at 14:36 +0800, James Pang wrote:
> we faced into a lot of=C2=A0 lwlock:LockManager wait-events , all of thes=
e queries=C2=A0are "select ..." ,
> there are other several session are doing DML, insert/update/delete on sa=
me table.
> Did these DML transactions holding "transactionid" and "tuple" lock block=
ing=C2=A0"select" on lwlock:LockManager ?

This is not about waiting for a lock.  Rather, it means that very many sess=
ions 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 effe=
ctive connection
pool *might* solve that particular problem.

Yours,
Laurenz Albe