| From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
|---|---|
| To: | James Pang <jamespang886(at)gmail(dot)com>, pgsql-performance(at)lists(dot)postgresql(dot)org |
| Subject: | Re: LWlock:LockManager waits |
| Date: | 2024-04-09 04:31:48 |
| Message-ID: | 4d260f0d07074479808f893b1457af3a48c55355.camel@cybertec.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Tue, 2024-04-09 at 11:07 +0800, James Pang wrote:
> we found sometimes , with many sessions running same query "select ..." at the same time, saw many sessions waiting on "LockManager". for example, pg_stat_activity show. It's a production server, so no enable trace_lwlocks flag. could you direct me what's the possible reason and how to reduce this "lockmanager" lock? all the sql statement are "select " ,no DML.
>
> time wait_event count(pid)
> 2024-04-08 09:00:06.043996+00 | DataFileRead | 42
> 2024-04-08 09:00:06.043996+00 | | 15
> 2024-04-08 09:00:06.043996+00 | LockManager | 31
> 2024-04-08 09:00:06.043996+00 | BufferMapping | 46
> 2024-04-08 09:00:07.114015+00 | LockManager | 43
> 2024-04-08 09:00:07.114015+00 | DataFileRead | 28
> 2024-04-08 09:00:07.114015+00 | ClientRead | 11
> 2024-04-08 09:00:07.114015+00 | | 11
That's quite obvious: too many connections cause internal contention in the database.
Reduce the number of connections by using a reasonably sized connection pool.
Yours,
Laurenz Albe
| From | Date | Subject | |
|---|---|---|---|
| Next Message | James Pang | 2024-04-09 07:54:45 | Re: LWlock:LockManager waits |
| Previous Message | James Pang | 2024-04-09 03:07:49 | LWlock:LockManager waits |