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

From Simon Riggs
Subject Straightforward changes for increased SMP scalability
Date
Msg-id 1184588626.5125.105.camel@ebony.site
Whole thread Raw
Responses Re: Straightforward changes for increased SMP scalability  ("Joshua D. Drake" <jd@commandprompt.com>)
Re: Straightforward changes for increased SMP scalability  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Straightforward changes for increased SMP scalability  (Andrew Sullivan <ajs@crankycanuck.ca>)
Re: Straightforward changes for increased SMP scalability  (Bruce Momjian <bruce@momjian.us>)
Re: Straightforward changes for increased SMP scalability  (Bruce Momjian <bruce@momjian.us>)
Re: Straightforward changes for increased SMP scalability  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
David Strong presented some excellent results of his SMP scalability
testing at Ottawa in May.
http://www.pgcon.org/2007/schedule/events/16.en.html

There are some easy things we can do to take advantage of those results,
especially the ones that were hardware independent.

The hardware independent results were these two:
- Avoid contention on WALInsertLock (+28% gain)
- Increase NUM_BUFFER_PARTITIONS (+7.7% gain)

Scalability begins to slow down at 8 CPUs on 8.2.4 and David was able to
show good gains even at 8 CPUs with these changes.

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?

--  Simon Riggs EnterpriseDB  http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: write_pipe_chunks patch messes up early error message output
Next
From: Martin Pihlak
Date:
Subject: Re: stored procedure stats in collector