Re: Parallel Select query performance and shared buffers - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Parallel Select query performance and shared buffers
Date
Msg-id 20131205091841.GE28793@alap2.anarazel.de
Whole thread Raw
In response to Re: Parallel Select query performance and shared buffers  (Metin Doslu <metin@citusdata.com>)
Responses Re: Parallel Select query performance and shared buffers  (Metin Doslu <metin@citusdata.com>)
Re: Parallel Select query performance and shared buffers  (Metin Doslu <metin@citusdata.com>)
List pgsql-hackers
On 2013-12-05 11:15:20 +0200, Metin Doslu wrote:
> > - When we increased NUM_BUFFER_PARTITIONS to 1024, this problem is
> > disappeared for 8 core machines and come back with 16 core machines on
> > Amazon EC2. Would it be related with PostgreSQL locking mechanism?
>
> If we build with -DLWLOCK_STATS to print locking stats from PostgreSQL, we
> see tons of contention with default value of NUM_BUFFER_PARTITIONS which is
> 16:

Is your workload bigger than RAM? I think a good bit of the contention
you're seeing in that listing is populating shared_buffers - and might
actually vanish once you're halfway cached.
From what I've seen so far the bigger problem than contention in the
lwlocks itself, is the spinlock protecting the lwlocks...

Greetings,

Andres Freund

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


pgsql-hackers by date:

Previous
From: Metin Doslu
Date:
Subject: Re: Parallel Select query performance and shared buffers
Next
From: Metin Doslu
Date:
Subject: Re: Parallel Select query performance and shared buffers