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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-performance by date

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