From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Metin Doslu <metin(at)citusdata(dot)com> |
Cc: | postgres performance list <pgsql-performance(at)postgresql(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Claudio Freire <klaussfreire(at)gmail(dot)com> |
Subject: | Re: Parallel Select query performance and shared buffers |
Date: | 2013-12-05 09:18:41 |
Message-ID: | 20131205091841.GE28793@alap2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Metin Doslu | 2013-12-05 09:33:29 | Re: Parallel Select query performance and shared buffers |
Previous Message | Metin Doslu | 2013-12-05 09:15:20 | Re: Parallel Select query performance and shared buffers |
From | Date | Subject | |
---|---|---|---|
Next Message | Metin Doslu | 2013-12-05 09:33:29 | Re: Parallel Select query performance and shared buffers |
Previous Message | Metin Doslu | 2013-12-05 09:15:20 | Re: Parallel Select query performance and shared buffers |