From: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Straightforward changes for increased SMP scalability |
Date: | 2007-07-16 14:44:05 |
Message-ID: | 469B8435.4060705@commandprompt.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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/
From | Date | Subject | |
---|---|---|---|
Next Message | Strong, David | 2007-07-16 15:13:24 | Re: Straightforward changes for increased SMP scalability |
Previous Message | Heikki Linnakangas | 2007-07-16 14:39:07 | Re: Dealing with dangling index pointers |