Re: Two identical systems, radically different performance - Mailing list pgsql-performance

From Craig James
Subject Re: Two identical systems, radically different performance
Date
Msg-id CAFwQ8rcW744OLOF5FX4=+Q3rizXvPaX0w8POcWp0qsvD6vCBLQ@mail.gmail.com
Whole thread Raw
In response to Re: Two identical systems, radically different performance  (Andrea Suisani <sickpig@opinioni.net>)
List pgsql-performance
On Wed, Oct 17, 2012 at 11:57 PM, Andrea Suisani <sickpig@opinioni.net> wrote:
> On 10/17/2012 06:35 PM, Scott Marlowe wrote:
>>
>> On Wed, Oct 17, 2012 at 9:45 AM, Andrea Suisani <sickpig@opinioni.net>
>> wrote:
>>>
>>> On 10/15/2012 05:34 PM, Scott Marlowe wrote:
>>>>
>>>> I'd recommend more synthetic benchmarks when trying to compare systems
>>>> like this.  bonnie++,
>>>
>>>
>>>
>>> you were right. bonnie++ (-f -n 0 -c 4) show that there's very little (if
>>> any)
>>> difference in terms of sequential input whether or not cache is enabled
>>> on
>>> the
>>> RAID1 (SAS 15K, sdb).
>
>
> Maybe there's a misunderstanding here.. :) Craig (James) is the one
> the had started this thread. I've joined later suggesting a way to
> disable HT without rebooting (using sysfs interface), trying to avoid
> a trip to the data-center to Craig.
>
> At that point Claudio Freire wondering if disabling HT from sysfs
> would have removed the performance penalty that Craig has experienced.
>
> So I decided to test this on a brand new box that I've just bought.
>
> When performing this test I've discovered by chance that
> the raid controller (PERC H710) behave in an unexpected way,
> cause the hw cache has almost no effect in terms of TPS in
> a pgbench session.
>
>> I'm mainly wanting to know the difference between the two systems, so
>> if you can run it on the old and new machine and compare that that's
>> the real test.
>
>
> This is something that Craig can do.

Too late ... the new machine is in production.

Craig

>
> [cut]
>
>>> I dunno why but I would have expected a higher delta (due to the 512MB
>>> cache)
>>> not a mere 10MB/s, but this is only based on my gut feeling.
>
>>
>>
>> Well the sequential throughput doesn't really rely on caching.  It's
>> the random writes that benefit from caching, and the other things
>> (random reads and seq read/write) that indirectly benefit because the
>> random writes are so much faster that they no longer get in the way.
>> So mostly compare random access between the old and new machines and
>> look for differences there.
>
>
> make sense.
>
> I will focus on tests that measure random path access.
>
>>>>   the memory stream test that Greg Smith was
>>>> working on, and so on.
>>>
>>>
>>>
>>> this one https://github.com/gregs1104/stream-scaling, right?
>>
>>
>> Yep.
>>
>>> I've executed the test with HT enabled, HT disabled from the BIOS
>>> and HT disable using sys interface. Attached 3 graphs and related
>>> text files
>>
>>
>> Well it's pretty meh.
>
>
> :/
>
> do you think that Xeon Xeon 5620 perform poorly ?
>
>> I'd like to see the older machine compared to
>> the newer one here tho.
>
>
> also this one is on Craig side.
>
>>> I'm trying... hard :)
>>
>>
>> You're doing great.  These problems take effort to sort out.
>
>
> thanks
>
>


pgsql-performance by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Unused index influencing sequential scan plan
Next
From: Tom Lane
Date:
Subject: Re: Unused index influencing sequential scan plan