From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Ashkil Dighin <ashkildighin76(at)gmail(dot)com> |
Cc: | pgsql-performance(at)lists(dot)postgresql(dot)org |
Subject: | Re: LwLockRelease performance |
Date: | 2021-12-02 23:50:44 |
Message-ID: | 20211202235044.wa2vzrpc5bocdmkn@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Hi,
On 2021-12-01 19:56:11 +0530, Ashkil Dighin wrote:
> The performance bottleneck in LWLockRelease()method goes through an array
> one by one to see which lock was released with O(N). As soon as the lock is
> found it performs an array to remove the lock.
> As linear search and compaction delays the release of the lock forcing the
> other Postgres instances WAiting for the lock to be released
> Is any possible solution like
> 1. LWLockRelease() releases the lock first and then remove held lock from
> the array
You currently can't really - we don't know the to-be-released lockmode without
the lookup in the array. You could try to reason it based on the current state
of the lock, but that doesn't strike me as a great idea either.
> 2. Binary search (like non-linear structure) to reduce on high searching
> and remove all held locks
That'd likely lead to considerably worse performance. Due to the unpredictable
branches binary search is worse than linear search at low-ish array values
(obviously depends on the cost of a comparison etc).
Do you have a workload where this is a significant issue? Most of the time we
do not hold enough lwlocks for it to be a problem. I've seen it become a
bottleneck during my AIO work (*) - but IIRC I worked around it.
IIRC I observed the shifting of the locks to be the bigger issue than the
search for the locks themselves. It might be worth experimenting with not
shifting allt he subsequent locks, but instead just swapping in the
currently-last lock.
Greetings,
Andres Freund
(*) IIRC the issue is when writing back we try to write back multiple buffers
at once (using conditional lock acquisition to avoid deadlocks). Those then
are likely released in FIFO order. I think it's now not a problem anymore
because I ended up introducing the concept of locks that are owned by the AIO
subsystem for other reasons.
From | Date | Subject | |
---|---|---|---|
Next Message | ldh@laurent-hasson.com | 2021-12-04 17:32:10 | An I/O error occurred while sending to the backend (PG 13.4) |
Previous Message | Tom Lane | 2021-12-02 22:19:39 | Re: LwLockRelease performance |