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
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 |