Re: Straightforward changes for increased SMP scalability - Mailing list pgsql-hackers

From Strong, David
Subject Re: Straightforward changes for increased SMP scalability
Date
Msg-id B6419AF36AC8524082E1BC17DA2506E803CE9232@USMV-EXCH2.na.uis.unisys.com
Whole thread Raw
In response to Re: Straightforward changes for increased SMP scalability  ("Joshua D. Drake" <jd@commandprompt.com>)
Responses Re: Straightforward changes for increased SMP scalability  ("Zeugswetter Andreas ADI SD" <Andreas.Zeugswetter@s-itsolutions.at>)
List pgsql-hackers
>Simon Riggs wrote:
>
>> Proposals
>>
>> 1. For the first result, I suggest that we introduce some padding
into
>> the shmem structure XLogCtlData to alleviate false sharing that may
>> exist between holders of WALInsertLock, WALWriteLock and info_lck.
The
>> cost of this will be at most about 200 bytes of shmem, with a low
risk
>> change. The benefits are hard to quantify, but we know this is an
area
>> of high contention and we should do all we can to reduce that.
>> This hasn't been discussed previously, though we have seen good
benefit
>> from avoiding false sharing in other cases, e.g. LWLOCK padding.
>>
>> 2. Increase NUM_BUFFER_PARTITIONS from 16 to 256 (or higher).
>> This has been discussed previously:
>> http://archives.postgresql.org/pgsql-hackers/2006-09/msg00967.php
>>
>> Both of these changes are simple enough to consider for 8.3
>>
>> Comments?
>>
>+1 on the idea (I can speak to the technical side). What I can say is
>that it is pretty much known that after 8 cores we slow down. Although
>8.2 is better than any other release in this regard.
>
>Joshua D. Drake
>
Here's a quick update. We're working on moving the patches we made
against Postgres 8.2.4 to 8.3 to see what is still valid. So far, the
base 8.3 shows ~7% improvement at 8 cores over 8.2.4.

The NUM_BUFFER_PARTITIONS patch is fairly simple. We've noticed gains
with NUM_BUFFER_PARTITIONS set between 256 and 2048, but little to no
gain after 2048, although this might depend on the benchmark and
platform being used. We've measured ~3% gain from the 8.3 base with
NUM_BUFFER_PARTITIONS set to 2048. This might be the way this patch
behaves with 8.3 or we might find that the NUM_BUFFER_PARTITIONS patch
complements patch "X" as the 7.7% number reported for
NUM_BUFFER_PARTITIONS in our presentation had a number of other patches
enabled. This was also running at a 20 cores.

We plan to start releasing patches this week for your consideration,
along with their current gains.

David

--
      === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997             http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings


pgsql-hackers by date:

Previous
From: Michael Meskes
Date:
Subject: Re: minor compiler warning on OpenBSD
Next
From: Andrew Dunstan
Date:
Subject: Re: Straightforward changes for increased SMP scalability