From: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: CPUs for new databases |
Date: | 2010-10-27 19:17:20 |
Message-ID: | AANLkTi=bDORtyHZVB4XSpE=SN0EzPObZQFn40qo-cgk+@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Wed, Oct 27, 2010 at 12:28 PM, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> wrote:
> On Wed, Oct 27, 2010 at 12:03 PM, Josh Berkus <josh(at)agliodbs(dot)com> 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 memory at the same time.
>>
>> Well, the next step then is to do some database server benchmarking.
>>
>> My experience has been that PostgreSQL scales poorly past 30 cores, or
>> even at lower levels depending on the workload. So it would be
>> interesting to see if the memory bandwidth on the AMDs makes up for our
>> scaling issues.
>
> Which OSes have you tested it on? And what hardware? For smaller
> operations, like pgbench, where a large amount of what you're working
> on fits in cache, I get near linear scaling right up to 48 cores.
> Overall performance increases til about 50 threads, then drops off to
> about 60 to 70% peak for the next hundred or so threads I add on.
And that's with 8.3.latest on ubuntu 10.04 with latest updates on HW RAID.
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pitts | 2010-10-27 19:23:31 | Re: temporary tables, indexes, and query plans |
Previous Message | Andreas Kretschmer | 2010-10-27 18:58:04 | Re: Massive update, memory usage |