you mean too many concurrent sessions trying to acquire lock on same relation , then waiting on "LockManager" LWlock,right? this contention occurred on parsing ,planning, or execute step ?
Thanks, James Laurenz Albe <laurenz.a...@cybertec.at> 於 2024年4月9日週二 下午12:31寫道： > 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 >
