On Nov 26, 2010, at 2:30 PM, Greg Smith wrote:
>
> 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 sour
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, a
"Christian Elmerot @ One.com" wrote:
> Highest results comes at 32 threads:
It would be interesting to see the results if you built a version of
PostgreSQL with LOG2_NUM_LOCK_PARTITIONS set to 6 (instead of 4).
-Kevin
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresq
On 2010-10-27 21:58, Greg Smith wrote:
Ivan Voras wrote:
FWIW, yes - once the IO is fast enough or not necessary (e.g. the
read-mostly database fits in RAM), RAM bandwidth *is* the next
bottleneck and it really, really can be observed in actual loads.
This is exactly what I've concluded, afte
Hello,
What is the general view of performance CPU's nowadays when it comes to
PostgreSQL performance? Which CPU is the better choice, in regards to
RAM access-times, stream speed, cache synchronization etc. Which is the
better CPU given the limitation of using AMD64 (x86-64)?
We're getting
Ivan Voras wrote:
FWIW, yes - once the IO is fast enough or not necessary (e.g. the
read-mostly database fits in RAM), RAM bandwidth *is* the next
bottleneck and it really, really can be observed in actual loads.
This is exactly what I've concluded, after many rounds of correlating
memory spe
On Wed, Oct 27, 2010 at 12:28 PM, Scott Marlowe wrote:
> On Wed, Oct 27, 2010 at 12:03 PM, Josh Berkus wrote:
>> On 10/26/10 6:14 PM, Scott Marlowe wrote:
>>> There was an earlier thread with
>>> Greg and I in it where we posted the memory bandwidth numbers for that
>>> machine and it was insan
On Wed, Oct 27, 2010 at 12:03 PM, Josh Berkus wrote:
> On 10/26/10 6:14 PM, Scott Marlowe wrote:
>> There was an earlier thread with
>> Greg and I in it where we posted the memory bandwidth numbers for that
>> machine and it was insane how much data all 48 cores could pump into /
>> out of memor
On 10/26/10 6:14 PM, Scott Marlowe wrote:
> There was an earlier thread with
> Greg and I in it where we posted the memory bandwidth numbers for that
> machine and it was insane how much data all 48 cores could pump into /
> out of memory at the same time.
Well, the next step then is to do some
One last note. Our vendor at the time we ordered our quad 12 core
machines could only provide that mobo in a 1U chassis. Consequently
we bought all external arrays for that machine. Since you're looking
at a dual 8 core machine, you should be able to get a mobo like that
in almost any chassis yo
On Wed, Oct 27, 2010 at 1:37 AM, Yeb Havinga wrote:
> Scott Marlowe wrote:
>>
>> There was an earlier thread with
>> Greg and I in it where we posted the memory bandwidth numbers for that
>> machine and it was insane how much data all 48 cores could pump into /
>> out of memory at the same time.
>
Scott Marlowe wrote:
There was an earlier thread with
Greg and I in it where we posted the memory bandwidth numbers for that
machine and it was insane how much data all 48 cores could pump into /
out of memory at the same time.
Yeah, it was insane. Building a economical 'that generation optero
On Tue, Oct 26, 2010 at 6:18 PM, Ivan Voras wrote:
> FWIW, yes - once the IO is fast enough or not necessary (e.g. the
> read-mostly database fits in RAM), RAM bandwidth *is* the next bottleneck
> and it really, really can be observed in actual loads. Buying a QPI-based
> CPU instead of the cheape
On 10/27/10 01:45, James Cloos wrote:
"JB" == Josh Berkus writes:
JB> In a general workload, fewer faster cores are better. We do not scale
JB> perfectly across cores. The only case where that's not true is
JB> maintaining lots of idle connections, and that's really better dealt
JB> with
> "JB" == Josh Berkus writes:
JB> In a general workload, fewer faster cores are better. We do not scale
JB> perfectly across cores. The only case where that's not true is
JB> maintaining lots of idle connections, and that's really better dealt
JB> with in software.
I've found that ram spee
On 10/26/10 7:50 AM, Scott Marlowe wrote:
> For faster but fewer individual cores the Intels are pretty good. For
> way more cores, each being pretty fast and having enough memory
> bandwidth to use all those cores, the AMDs are very impressive. The
> Magny Cours AMDs are probably the best 4 sock
On 2010-10-26 16:27, Kevin Grittner wrote:
Christian Elmerot wrote:
What is the general view of performance CPU's nowadays when it
comes to PostgreSQL performance? Which CPU is the better choice,
in regards to RAM access-times, stream speed, cache
synchronization etc. Which is the better CPU g
On Tue, Oct 26, 2010 at 6:55 AM, Christian Elmerot wrote:
> Hello,
>
> What is the general view of performance CPU's nowadays when it comes to
> PostgreSQL performance? Which CPU is the better choice, in regards to RAM
> access-times, stream speed, cache synchronization etc. Which is the better
>
Christian Elmerot wrote:
> What is the general view of performance CPU's nowadays when it
> comes to PostgreSQL performance? Which CPU is the better choice,
> in regards to RAM access-times, stream speed, cache
> synchronization etc. Which is the better CPU given the limitation
> of using AMD64
Hello,
What is the general view of performance CPU's nowadays when it comes to
PostgreSQL performance? Which CPU is the better choice, in regards to
RAM access-times, stream speed, cache synchronization etc. Which is the
better CPU given the limitation of using AMD64 (x86-64)?
We're getting
20 matches
Mail list logo
