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

From Joshua D. Drake
Subject Re: Straightforward changes for increased SMP scalability
Date
Msg-id 469B8435.4060705@commandprompt.com
Whole thread Raw
In response to Straightforward changes for increased SMP scalability  ("Simon Riggs" <simon@2ndquadrant.com>)
Responses Re: Straightforward changes for increased SMP scalability
Re: Straightforward changes for increased SMP scalability
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

> 


-- 
      === 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/



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Dealing with dangling index pointers
Next
From: Tom Lane
Date:
Subject: Re: Dealing with dangling index pointers