Обсуждение: Fw: [HACKERS] HACKERS[PATCH] split ProcArrayLock into multiple parts --follow-up

Поиск
Список
Период
Сортировка

Fw: [HACKERS] HACKERS[PATCH] split ProcArrayLock into multiple parts --follow-up

От
"Jim Van Fleet"
Дата:
Howdy --

Not to beat on a dead horse, or anything, but this fix was frowned upon because in one environment (one socket) it was 6% down and over 15% up in the right environment (two sockets).

So, why not add a configuration parameter which specifies the number of parts? Default is 1 which would be "exactly" the same as no parts and hence no degradation in the single socket environment -- and with 2, you get some positive performance.

Jim
----- Forwarded by Jim Van Fleet/Austin/Contr/IBM on 09/21/2017 03:37 PM -----

pgsql-hackers-owner@postgresql.org wrote on 06/09/2017 01:39:35 PM:

> From: "Jim Van Fleet" <vanfleet@us.ibm.com>
> To: "Pgsql Hackers" <pgsql-hackers@postgresql.org>
> Date: 06/09/2017 01:41 PM
> Subject: [HACKERS] HACKERS[PATCH] split ProcArrayLock into multiple parts
> Sent by: pgsql-hackers-owner@postgresql.org
>
> I left out the retry in LWLockAcquire.
>
> [attachment "ProcArrayLock_part.patch" deleted by Jim Van Fleet/
> Austin/Contr/IBM]
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

Re: Fw: [HACKERS] HACKERS[PATCH] split ProcArrayLock into multipleparts -- follow-up

От
Andres Freund
Дата:
On 2017-09-21 15:51:54 -0500, Jim Van Fleet wrote:
> Not to beat on a dead horse, or anything, but this fix was frowned upon 
> because in one environment (one socket) it was 6% down and over 15% up in 
> the right environment (two sockets).

> So, why not add a configuration parameter which specifies the number of 
> parts? Default is 1 which would be "exactly" the same as no parts and 
> hence no degradation in the single socket environment -- and with 2, you 
> get some positive performance.

Several reasons:

- You'd either add a bunch of branches into a performance critical parts, or you'd add a compile time flag, which most
peoplewould be unable to toggle.
 
- It'd be something hard to tune, because even on multi-socket machines it'll be highly load dependant. E.g. workloads
thatlargely are bottlenecked in a single backend / few backends will probably regress as well.
 

FWIW, you started a new thread with this message, that doesn't seem
helpful?

Greetings,

Andres Freund


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: Fw: [HACKERS] HACKERS[PATCH] split ProcArrayLock into multiple parts --follow-up

От
"Jim Van Fleet"
Дата:

> On 2017-09-21 15:51:54 -0500, Jim Van Fleet wrote:
> > Not to beat on a dead horse, or anything, but this fix was frowned upon
> > because in one environment (one socket) it was 6% down and over 15% up in
> > the right environment (two sockets).
>
> > So, why not add a configuration parameter which specifies the number of
> > parts? Default is 1 which would be "exactly" the same as no parts and
> > hence no degradation in the single socket environment -- and with 2, you
> > get some positive performance.
>
> Several reasons:
>
> - You'd either add a bunch of branches into a performance critical
>   parts, or you'd add a compile time flag, which most people would be
>   unable to toggle.
I agree, no compile time flags -- but no extra testing in the main path -- gets set at init and not changed from there.
> - It'd be something hard to tune, because even on multi-socket machines
>   it'll be highly load dependant. E.g. workloads that largely are
>   bottlenecked in a single backend / few backends will probably regress
>   as well.
Workloads are hard to tune -- with the default, you have what you have today. If you "know" the issue is ProcArrayLock, then you have an alternative to try.
>
> FWIW, you started a new thread with this message, that doesn't seem
> helpful?

Sorry about that -- my mistake.

Jim