From: | "Luiz Fernando G(dot) Verona" <nandoverona(at)gmail(dot)com> |
---|---|
To: | James Pang <jamespang886(at)gmail(dot)com> |
Cc: | pgsql-performance(at)lists(dot)postgresql(dot)org |
Subject: | Re: LWlock:LockManager waits |
Date: | 2024-04-09 10:33:36 |
Message-ID: | CAOnodNFh_C=2_KsQo==wocvGOzaUt4nEAON8ph=GShicbJeo7Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Hi James,
Take a look here, in the links you will find many info and real examples
for LockManager issues.
https://ardentperf.com/2024/03/03/postgres-indexes-partitioning-and-lwlocklockmanager-scalability/
Luiz
On Tue, Apr 9, 2024 at 4:08 AM James Pang <jamespang886(at)gmail(dot)com> 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
>
> Thanks,
>
> James
>
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2024-04-12 05:45:52 | Re: Performance implications of 8K pread()s |
Previous Message | Frits Hoogland | 2024-04-09 09:36:41 | Re: LWlock:LockManager waits |