Re: LWlock:LockManager waits
| От | Laurenz Albe |
|---|---|
| Тема | Re: LWlock:LockManager waits |
| Дата | |
| Msg-id | 4d260f0d07074479808f893b1457af3a48c55355.camel@cybertec.at обсуждение исходный текст |
| Ответ на | [MASSMAIL]LWlock:LockManager waits (James Pang <jamespang886@gmail.com>) |
| Ответы |
Re: LWlock:LockManager waits
|
| Список | 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 waitingon "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
В списке pgsql-performance по дате отправления: