Re: Re: Misaligned BufferDescriptors causing major performance problems on AMD

От:

Tom Lane <tgl@sss.pgh.pa.us>

Дата:

5 февраля 2014 г. в 15:00:23

Re: Misaligned BufferDescriptors causing major performance problems on AMD

От:

Tom Lane <tgl@sss.pgh.pa.us>

Дата:

5 февраля 2014 г. в 16:24:44

Misaligned BufferDescriptors causing major performance problems on AMD

От:

Andres Freund <andres@2ndquadrant.com>

Дата:

2 февраля 2014 г. в 15:13:25

Hi,

In the nearby thread at
http://archives.postgresql.org/message-id/20140202140014.GM5930%40awork2.anarazel.de
Peter and I discovered that there is a large performance difference
between different max_connections on a larger machine (4x Opteron 6272,
64 cores together) in a readonly pgbench tests...

Just as reference, we're talking about a performance degradation from
475963.613865 tps to 197744.913556 in a pgbench -S -cj64 just by setting
max_connections to 90, from 91...

On 2014-02-02 15:00:14 +0100, Andres Freund wrote:
> On 2014-02-01 19:47:29 -0800, Peter Geoghegan wrote:
> > Here are the results of a benchmark on Nathan Boley's 64-core, 4
> > socket server: http://postgres-benchmarks.s3-website-us-east-1.amazonaws.com/amd-4-socket-rwlocks/
>
> That's interesting. The maximum number of what you see here (~293125)
> is markedly lower than what I can get.
>
> ... poke around ...
>
> Hm, that's partially because you're using pgbench without -M prepared if
> I see that correctly. The bottleneck in that case is primarily memory
> allocation. But even after that I am getting higher
> numbers: ~342497.
>
> Trying to nail down the differnce it oddly seems to be your
> max_connections=80 vs my 100. The profile in both cases is markedly
> different, way much more spinlock contention with 80. All in
> Pin/UnpinBuffer().
>
> I think =80 has to lead to some data being badly aligned. I can
> reproduce that =91 has *much* better performance than =90. 170841.844938
> vs 368490.268577 in a 10s test. Reproducable both with an without the test.
> That's certainly worth some investigation.
> This is *not* reproducable on the intel machine, so it might the
> associativity of the L1/L2 cache on the AMD.

So, I looked into this, and I am fairly certain it's because of the
(mis-)alignment of the buffer descriptors. With certain max_connections
settings InitBufferPool() happens to get 64byte aligned addresses, with
others not. I checked the alignment with gdb to confirm that.

A quick hack (attached) making BufferDescriptor 64byte aligned indeed
restored performance across all max_connections settings. It's not
surprising that a misaligned buffer descriptor causes problems -
there'll be plenty of false sharing of the spinlocks otherwise. Curious
that the the intel machine isn't hurt much by this.

Now all this hinges on the fact that by a mere accident
BufferDescriptors are 64byte in size:
struct sbufdesc {
        BufferTag                  tag;                  /*     0    20 */
        BufFlags                   flags;                /*    20     2 */
        uint16                     usage_count;          /*    22     2 */
        unsigned int               refcount;             /*    24     4 */
        int                        wait_backend_pid;     /*    28     4 */
        slock_t                    buf_hdr_lock;         /*    32     1 */

        /* XXX 3 bytes hole, try to pack */

        int                        buf_id;               /*    36     4 */
        int                        freeNext;             /*    40     4 */

        /* XXX 4 bytes hole, try to pack */

        LWLock *                   io_in_progress_lock;  /*    48     8 */
        LWLock *                   content_lock;         /*    56     8 */
        /* --- cacheline 1 boundary (64 bytes) --- */

        /* size: 64, cachelines: 1, members: 10 */
        /* sum members: 57, holes: 2, sum holes: 7 */
};

We could polish up the attached patch and apply it to all the branches,
the costs of memory are minimal. But I wonder if we shouldn't instead
make ShmemInitStruct() always return cacheline aligned addresses. That
will require some fiddling, but it might be a good idea nonetheless?

I think we should also consider some more reliable measures to have
BufferDescriptors cacheline sized, rather than relying on the happy
accident. Debugging alignment issues isn't fun, too much of a guessing
game...

Thoughts?

Greetings,

Andres Freund

--
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Re: Re: Misaligned BufferDescriptors causing major performance problems on AMD

От:

Andres Freund <andres@2ndquadrant.com>

Дата:

3 февраля 2014 г. в 23:38:25

Re: Re: Misaligned BufferDescriptors causing major performance problems on AMD

От:

Andres Freund <andres@2ndquadrant.com>

Дата:

4 февраля 2014 г. в 12:21:06

Re: Re: Misaligned BufferDescriptors causing major performance problems on AMD

От:

Andres Freund <andres@2ndquadrant.com>

Дата:

5 февраля 2014 г. в 08:10:41

Re: Re: Misaligned BufferDescriptors causing major performance problems on AMD

От:

Andres Freund <andres@2ndquadrant.com>

Дата:

5 февраля 2014 г. в 15:08:56

Re: Misaligned BufferDescriptors causing major performance problems on AMD

От:

Andres Freund <andres@2ndquadrant.com>

Дата:

5 февраля 2014 г. в 15:21:48

Re: Misaligned BufferDescriptors causing major performance problems on AMD

От:

Andres Freund <andres@2ndquadrant.com>

Дата:

5 февраля 2014 г. в 16:37:42

Re: Misaligned BufferDescriptors causing major performance problems on AMD

От:

Andres Freund <andres@2ndquadrant.com>

Дата:

6 февраля 2014 г. в 08:40:44

Re: Misaligned BufferDescriptors causing major performance problems on AMD

От:

Bruce Momjian <bruce@momjian.us>

Дата:

16 апреля 2014 г. в 23:18:09

Re: Misaligned BufferDescriptors causing major performance problems on AMD

От:

Andres Freund <andres@2ndquadrant.com>

Дата:

17 апреля 2014 г. в 09:23:34

Re: Misaligned BufferDescriptors causing major performance problems on AMD

От:

Bruce Momjian <bruce@momjian.us>

Дата:

26 августа 2014 г. в 02:58:29

Re: Misaligned BufferDescriptors causing major performance problems on AMD

От:

Bruce Momjian <bruce@momjian.us>

Дата:

24 декабря 2014 г. в 03:51:37

On Thu, Apr 17, 2014 at 11:23:24AM +0200, Andres Freund wrote:
> On 2014-04-16 19:18:02 -0400, Bruce Momjian wrote:
> > On Thu, Feb  6, 2014 at 09:40:32AM +0100, Andres Freund wrote:
> > > On 2014-02-05 12:36:42 -0500, Robert Haas wrote:
> > > > >> It may well be that your proposal is spot on.  But I'd like to see some
> > > > >> data-structure-by-data-structure measurements, rather than assuming that
> > > > >> alignment must be a good thing.
> > > > >
> > > > > I am fine with just aligning BufferDescriptors properly. That has
> > > > > clearly shown massive improvements.
> > > > 
> > > > I thought your previous idea of increasing BUFFERALIGN to 64 bytes had
> > > > a lot to recommend it.
> > > 
> > > Good.
> > > 
> > > I wonder if we shouldn't move that bit of logic:
> > > 	if (size >= BUFSIZ)
> > > 		newStart = BUFFERALIGN(newStart);
> > > out of ShmemAlloc() and instead have a ShmemAllocAligned() and
> > > ShmemInitStructAligned() that does it. So we can sensibly can control it
> > > per struct.
> > > 
> > > > But that doesn't mean it doesn't need testing.
> > > 
> > > I feel the need here, to say that I never said it doesn't need testing
> > > and never thought it didn't...
> > 
> > Where are we on this?
> 
> It needs somebody with time to evaluate possible performance regressions
> - I personally won't have time to look into this in detail before pgcon.

I am doing performance testing to try to complete this item.  I used the
first attached patch to report which structures are 64-byte aligned:

	64-byte shared memory alignment of Control File:  0
	64-byte shared memory alignment of XLOG Ctl:  1
	64-byte shared memory alignment of CLOG Ctl:  0
	64-byte shared memory alignment of CommitTs Ctl:  0
	64-byte shared memory alignment of CommitTs shared:  0
	64-byte shared memory alignment of SUBTRANS Ctl:  1
	64-byte shared memory alignment of MultiXactOffset Ctl:  1
	64-byte shared memory alignment of MultiXactMember Ctl:  1
	64-byte shared memory alignment of Shared MultiXact State:  1
	64-byte shared memory alignment of Buffer Descriptors:  1
	64-byte shared memory alignment of Buffer Blocks:  1
	64-byte shared memory alignment of Shared Buffer Lookup Table:  1
	64-byte shared memory alignment of Buffer Strategy Status:  1
	64-byte shared memory alignment of LOCK hash:  0
	64-byte shared memory alignment of PROCLOCK hash:  0
	64-byte shared memory alignment of Fast Path Strong Relation Lock Data:  0
	64-byte shared memory alignment of PREDICATELOCKTARGET hash:  0
	64-byte shared memory alignment of PREDICATELOCK hash:  0
	64-byte shared memory alignment of PredXactList:  0
	64-byte shared memory alignment of SERIALIZABLEXID hash:  1
	64-byte shared memory alignment of RWConflictPool:  1
	64-byte shared memory alignment of FinishedSerializableTransactions:  0
	64-byte shared memory alignment of OldSerXid SLRU Ctl:  1
	64-byte shared memory alignment of OldSerXidControlData:  1
	64-byte shared memory alignment of Proc Header:  0
	64-byte shared memory alignment of Proc Array:  0
	64-byte shared memory alignment of Backend Status Array:  0
	64-byte shared memory alignment of Backend Application Name Buffer:  0
	64-byte shared memory alignment of Backend Client Host Name Buffer:  0
	64-byte shared memory alignment of Backend Activity Buffer:  0
	64-byte shared memory alignment of Prepared Transaction Table:  0
	64-byte shared memory alignment of Background Worker Data:  0
	64-byte shared memory alignment of shmInvalBuffer:  1
	64-byte shared memory alignment of PMSignalState:  0
	64-byte shared memory alignment of ProcSignalSlots:  0
	64-byte shared memory alignment of Checkpointer Data:  0
	64-byte shared memory alignment of AutoVacuum Data:  0
	64-byte shared memory alignment of Wal Sender Ctl:  0
	64-byte shared memory alignment of Wal Receiver Ctl:  0
	64-byte shared memory alignment of BTree Vacuum State:  0
	64-byte shared memory alignment of Sync Scan Locations List:  0
	64-byte shared memory alignment of Async Queue Control:  0
	64-byte shared memory alignment of Async Ctl:  0

Many of these are 64-byte aligned, including Buffer Descriptors.  I
tested pgbench with these commands:

	$ pgbench -i -s 95 pgbench
	$ pgbench -S -c 95 -j 95 -t 100000 pgbench

on a 16-core Xeon server and got 84k tps.  I then applied another patch,
attached, which causes all the structures to be non-64-byte aligned, but
got the same tps number.

Can someone test these patches on an AMD CPU and see if you see a
difference?  Thanks.

-- 
  Bruce Momjian          http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +

Re: Misaligned BufferDescriptors causing major performance problems on AMD

От:

Andres Freund <andres@2ndquadrant.com>

Дата:

24 декабря 2014 г. в 09:30:29

Re: Misaligned BufferDescriptors causing major performance problems on AMD

От:

Bruce Momjian <bruce@momjian.us>

Дата:

24 декабря 2014 г. в 15:00:14

Re: Misaligned BufferDescriptors causing major performance problems on AMD

От:

Andres Freund <andres@2ndquadrant.com>

Дата:

24 декабря 2014 г. в 16:20:24

Re: Misaligned BufferDescriptors causing major performance problems on AMD

От:

Bruce Momjian <bruce@momjian.us>

Дата:

29 декабря 2014 г. в 21:59:22

On Sat, Dec 27, 2014 at 08:05:42PM -0500, Robert Haas wrote:
> On Wed, Dec 24, 2014 at 11:20 AM, Andres Freund  wrote:
> > I just verified that I can still reproduce the problem:
> >
> > # aligned case (max_connections=401)
> > afreund@axle:~$ pgbench -P 1 -h /tmp/ -p5440 postgres -n -M prepared -c 96 -j 96 -T 100 -S
> > progress: 1.0 s, 405170.2 tps, lat 0.195 ms stddev 0.928
> > progress: 2.0 s, 467011.1 tps, lat 0.204 ms stddev 0.140
> > progress: 3.0 s, 462832.1 tps, lat 0.205 ms stddev 0.154
> > progress: 4.0 s, 471035.5 tps, lat 0.202 ms stddev 0.154
> > progress: 5.0 s, 500329.0 tps, lat 0.190 ms stddev 0.132
> >
> > BufferDescriptors is at 0x7f63610a6960 (which is 32byte aligned)
> >
> > # unaligned case (max_connections=400)
> > afreund@axle:~$ pgbench -P 1 -h /tmp/ -p5440 postgres -n -M prepared -c 96 -j 96 -T 100 -S
> > progress: 1.0 s, 202271.1 tps, lat 0.448 ms stddev 1.232
> > progress: 2.0 s, 223823.4 tps, lat 0.427 ms stddev 3.007
> > progress: 3.0 s, 227584.5 tps, lat 0.414 ms stddev 4.760
> > progress: 4.0 s, 221095.6 tps, lat 0.410 ms stddev 4.390
> > progress: 5.0 s, 217430.6 tps, lat 0.454 ms stddev 7.913
> > progress: 6.0 s, 210275.9 tps, lat 0.411 ms stddev 0.606
> > BufferDescriptors is at 0x7f1718aeb980 (which is 64byte aligned)
> 
> So, should we increase ALIGNOF_BUFFER from 32 to 64?  Seems like
> that's what these results are telling us.

I am glad someone else considers this important.  Andres reported the
above 2x pgbench difference in February, but no action was taken as
everyone felt there needed to be more performance testing, but it never
happened:

	http://www.postgresql.org/message-id/20140202151319.GD32123@awork2.anarazel.de

I have now performance tested this by developing the attached two
patches which both increase the Buffer Descriptors allocation by 64
bytes.  The first patch causes each 64-byte Buffer Descriptor struct to
align on a 32-byte boundary but not a 64-byte boundary, while the second
patch aligns it with a 64-byte boundary.

I tried many tests, including this:

	$ pgbench --initialize --scale 1 pgbench
	$ pgbench --protocol prepared --client 16 --jobs 16 --transactions 100000 --select-only pgbench

I cannot measure any difference on my dual-CPU-socket, 16-vcore server
(http://momjian.us/main/blogs/pgblog/2012.html#January_20_2012).   I
thought this test would cause the most Buffer Descriptor contention
between the two CPUs.  Can anyone else see a difference when testing
these two patches?  (The patch reports alignment in the server logs.)

-- 
  Bruce Momjian          http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +

Re: Misaligned BufferDescriptors causing major performance problems on AMD

От:

Andres Freund <andres@2ndquadrant.com>

Дата:

29 декабря 2014 г. в 23:48:30

Re: Misaligned BufferDescriptors causing major performance problems on AMD

От:

Andres Freund <andres@2ndquadrant.com>

Дата:

1 января 2015 г. в 16:59:54

Re: Misaligned BufferDescriptors causing major performance problems on AMD

От:

Bruce Momjian <bruce@momjian.us>

Дата:

1 января 2015 г. в 18:58:21

Re: Misaligned BufferDescriptors causing major performance problems on AMD

От:

Bruce Momjian <bruce@momjian.us>

Дата:

1 января 2015 г. в 20:16:10

Re: Misaligned BufferDescriptors causing major performance problems on AMD

От:

Andres Freund <andres@2ndquadrant.com>

Дата:

2 января 2015 г. в 17:26:16

Re: Misaligned BufferDescriptors causing major performance problems on AMD

От:

Bruce Momjian <bruce@momjian.us>

Дата:

6 января 2015 г. в 02:43:19

Re: Misaligned BufferDescriptors causing major performance problems on AMD

От:

Andres Freund <andres@2ndquadrant.com>

Дата:

27 января 2015 г. в 00:44:14

Re: Misaligned BufferDescriptors causing major performance problems on AMD

От:

Bruce Momjian <bruce@momjian.us>

Дата:

27 января 2015 г. в 00:58:36

Re: Misaligned BufferDescriptors causing major performance problems on AMD

От:

Andres Freund <andres@2ndquadrant.com>

Дата:

27 января 2015 г. в 01:04:34

Re: Misaligned BufferDescriptors causing major performance problems on AMD

От:

Andres Freund <andres@2ndquadrant.com>

Дата:

28 января 2015 г. в 11:47:42

Re: Misaligned BufferDescriptors causing major performance problems on AMD

От:

Andres Freund <andres@2ndquadrant.com>

Дата:

28 января 2015 г. в 15:43:42

Re: Misaligned BufferDescriptors causing major performance problems on AMD

От:

Andres Freund <andres@2ndquadrant.com>

Дата:

28 января 2015 г. в 16:09:02

Re: Misaligned BufferDescriptors causing major performance problems on AMD

От:

Andres Freund <andres@2ndquadrant.com>

Дата:

28 января 2015 г. в 18:17:38

On 2015-01-28 17:08:46 +0100, Andres Freund wrote:
> I just have no idea whether it'd be beneficial to use more space on
> 32bit to pad the individual entries. Since this mostly is beneficial on
> multi-socket, highly concurrent workloads, I doubt it really matter.

> I personally still think that a comment above sbufdesc's definition
> would be sufficient for now. But whatever. I'll enforce 64byte padding
> on 64bit platforms, and do nothing on 32bit platforms.

Patch doing that attached. I've for now dealt with the 32bit issue by:

#define BUFFERDESC_PADDED_SIZE	(sizeof(void*) == 8 ? 64 : sizeof(BufferDesc))
and
 * XXX: As this is primarily matters in highly concurrent workloads which
 * probably all are 64bit these days, and the space wastage would be a bit
 * more noticeable on 32bit systems, we don't force the stride to be cache
 * line sized. If somebody does actual performance testing, we can reevaluate.

I've replaced direct accesses to the (Local)BufferDescriptors array by a
wrapper macros to hide the union indirect and allow potential future
changes to be made more easily.

Greetings,

Andres Freund

-- 
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services