From: | Nikolay Samokhvalov <nik(at)postgres(dot)ai> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Configurable FP_LOCK_SLOTS_PER_BACKEND |
Date: | 2023-07-13 05:02:14 |
Message-ID: | CAM527d-uDn5osa6QPKxHAC6srOfBH3M8iXUM=ewqHV6n=w1u8Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
We're observing a few cases with lockmanager spikes in a few quite loaded
systems.
These cases are different; queries are different, Postgres versions are 12,
13, and 14.
But in all cases, servers are quite beefy (96-128 vCPUs, ~600-800 GiB)
receiving a lot of TPS (a few dozens of thousands). Most queries that
struggle from wait_event=lockmanager involve a substantial number of
tables/indexes, often with partitioning.
FP_LOCK_SLOTS_PER_BACKEND is now hard-coded 16 in storage/proc.h – and it
is now very easy to hit this threshold in a loaded system, especially, for
example, if a table with a dozen of indexes was partitioned. It seems any
system with good growth hits it sooner or later.
I wonder, would it make sense to:
1) either consider increasing this hard-coded value, taking into account
that 16 seems to be very low for modern workloads, schemas, and hardware –
say, it could be 64,
2) or even make it configurable – a new GUC.
Thanks,
Nikolay Samokhvalov
Founder, Postgres.ai
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2023-07-13 05:03:50 | Re: Changing types of block and chunk sizes in memory contexts |
Previous Message | Peter Smith | 2023-07-13 04:59:40 | Re: Consistent coding for the naming of LR workers |