Message-ID: <53FC5D04.8060908@catalyst.net.nz>
Date: Tue, 26 Aug 2014 22:10:12 +1200
From: Mark Kirkwood <mark.kirkwood@catalyst.net.nz>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Jeison Bedoya Delgado <jeisonb@audifarma.com.co>,
 "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Subject: Re: tuning postgresql 9.3.5 and multiple cores
References: <53FB84D2.5060808@audifarma.com.co>
In-Reply-To: <53FB84D2.5060808@audifarma.com.co>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

On 26/08/14 06:47, Jeison Bedoya Delgado wrote:
> hi, recently i change the hardware of my database 32 cores up to 64
> cores and 128GB Ram, but the performance is the same.  Perhaps i have to
> change any parameter in the postgresql.conf?.
>

In addition to the points that others have made, even if you do have > 
32 active sessions it it not clear that 64 cores will automagically get 
you twice (or in fact any) better performance than 32. We are seeing 
exactly this effect with a (60 core) machine that gets pretty much the 
same performance as an older generation 32 core one.

Interestingly while this is *likely* a software issue - it is not 
immediately obvious where it lies - we tested Postgres (9.3/9.4/9.5) and 
Mysql (5.5/5.6/5.7) *all* of which exhibited the the lack of improvement 
with more cores.

Profiling suggested numa effects - but trying to eliminate these seemed 
to simply throw up new factors to inhibit performance. My *guess* (and 
it is a guess) is that we are seeing 2 (perhaps more) performance 
bottlenecks very close to each other: numa and spinlock contention at least.

Regards

Mark


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance