Skip site navigation (1) Skip section navigation (2)

Re: CPUs for new databases

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: "Christian Elmerot (at) One(dot)com" <ce(at)one(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: CPUs for new databases
Date: 2010-11-26 22:30:16
Message-ID: 4CF034F8.5080606@2ndquadrant.com (view raw or flat)
Thread:
Lists: pgsql-performance
Christian Elmerot @ One.com wrote:
> Highest results comes at 32 threads:
> Number of Threads requested = 32
> Function      Rate (MB/s)   Avg time     Min time     Max time
> Triad:      81013.5506       0.0378       0.0377       0.0379

There is some run-to-run variation in the results of this test, and 
accordingly some margin for error in each individual result.  I wouldn't 
consider the difference between the speed at 32 threads (81) and 48 
(79.7) to be statistically significant, and based on the overall shape 
of the results curve that 32 result looks suspicious.  I would bet that 
if you run the test multiple times, you'd sometimes seen the 48 core one 
run faster than the 32.

> The pattern is quite clear in that any multiple of 4 (the number of 
> physical CPU packages) get a higher value but thinking about how the 
> memory is connected and utilized this makes perfect sense.

In addition to the memory issues, there's also thread CPU scheduling 
involved here.  Ideally the benchmark would pin each thread to a single 
core and keep it there for the runtime of the test, but it's not there 
yet.  I suspect one source of variation at odd numbers of threads 
involves processes that bounce between CPUs more than in the more even 
cases.

-- 
Greg Smith   2ndQuadrant US    greg(at)2ndQuadrant(dot)com   Baltimore, MD
PostgreSQL Training, Services and Support        www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books


In response to

Responses

pgsql-performance by date

Next:From: Mario SplivaloDate: 2010-11-28 11:46:11
Subject: SELECT INTO large FKyed table is slow
Previous:From: Kevin GrittnerDate: 2010-11-26 17:46:18
Subject: Re: CPUs for new databases

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group