Re: Reduce ProcArrayLock contention - Mailing list pgsql-hackers
| From | Amit Kapila |
|---|---|
| Subject | Re: Reduce ProcArrayLock contention |
| Date | |
| Msg-id | CAA4eK1+k0ekVhvta6Ms90TAqbpHL_kP3Pj94MBYTwx=c7HTLqQ@mail.gmail.com Whole thread Raw |
| In response to | Re: Reduce ProcArrayLock contention (Simon Riggs <simon@2ndQuadrant.com>) |
| Responses |
Re: Reduce ProcArrayLock contention
(Simon Riggs <simon@2ndQuadrant.com>)
|
| List | pgsql-hackers |
On Mon, Jun 29, 2015 at 10:52 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>
> On 29 June 2015 at 18:11, Andres Freund <andres@anarazel.de> wrote:
>>
>> On June 29, 2015 7:02:10 PM GMT+02:00, Simon Riggs <simon@2ndQuadrant.com> wrote:
>> >On 29 June 2015 at 16:27, Amit Kapila <amit.kapila16@gmail.com> wrote:
>> >
>> >
>> >> Thanks to Robert Haas for having discussion (offlist) about the idea
>> >> and suggestions to improve it and also Andres Freund for having
>> >> discussion and sharing thoughts about this idea at PGCon.
>> >>
>> >
>> >Weird. This patch is implemented exactly the way I said to implement it
>> >publicly at PgCon.
>> >
>> >Was nobody recording the discussion at the unconference??
>>
>> Amit presented an earlier version of this at the in unconference?
>
>
> Yes, I know. And we all had a long conversation about how to do it without waking up the other procs.
>
> Forming a list, like we use for sync rep and having just a single process walk the queue was the way I suggested then and previously.
>
>
> On 29 June 2015 at 18:11, Andres Freund <andres@anarazel.de> wrote:
>>
>> On June 29, 2015 7:02:10 PM GMT+02:00, Simon Riggs <simon@2ndQuadrant.com> wrote:
>> >On 29 June 2015 at 16:27, Amit Kapila <amit.kapila16@gmail.com> wrote:
>> >
>> >
>> >> Thanks to Robert Haas for having discussion (offlist) about the idea
>> >> and suggestions to improve it and also Andres Freund for having
>> >> discussion and sharing thoughts about this idea at PGCon.
>> >>
>> >
>> >Weird. This patch is implemented exactly the way I said to implement it
>> >publicly at PgCon.
>> >
>> >Was nobody recording the discussion at the unconference??
>>
>> Amit presented an earlier version of this at the in unconference?
>
>
> Yes, I know. And we all had a long conversation about how to do it without waking up the other procs.
>
> Forming a list, like we use for sync rep and having just a single process walk the queue was the way I suggested then and previously.
>
Yes, I remember very well about your suggestion which you have
given during Unconference and I really value that idea/suggestion.
Here, the point is that I could get chance to have in-person discussion
with Robert and Andres where they have spent more time discussing
about the problem (Robert has discussed about this much more apart
from PGCon as well), but that doesn't mean I am not thankful of the
ideas or suggestions I got from you and or others during Unconference.
Thank you for participating in the discussion and giving suggestions
and I really mean it, as I felt good about it even after wards.
Now, I would like to briefly explain how allow-one-waker idea has
helped to improve the patch as not every body here was present
in that Un-conference. The basic problem I was seeing during
initial version of patch was that I was using LWLockAcquireOrWait
call for all the clients who are not able to get ProcArrayLock
(conditionally in the first attempt) and then after waking each proc
was checking if it's XID is cleared and if not they were again try
to AcquireOrWait for ProcArrayLock, this was limiting the patch
to improve performance at somewhat moderate client count like
32 or 64 because even trying for LWLock in exclusive mode again
and again was the limiting factor (I have tried with
LWLockAcquireConditional as well instead of LWLockAcquireOrWait,
though it helped a bit but not very much). Allowing just one-client
to become kind of Group leader to clear the other proc's xid and wake
them-up and all the other proc's waiting after adding them to pendingClearXid
list has helped to reduce the bottleneck around procarraylock significantly.
pgsql-hackers by date: