LWlock:LockManager waits

2024-04-08 Thread James Pang
   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

Thanks,

James


Re: LWlock:LockManager waits

2024-04-08 Thread Laurenz Albe
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