Re: Two identical systems, radically different performance

Поиск
Список
Период
Сортировка
От Andrea Suisani
Тема Re: Two identical systems, radically different performance
Дата
Msg-id 507FA848.7040801@opinioni.net
обсуждение исходный текст
Ответ на Re: Two identical systems, radically different performance  (Scott Marlowe <scott.marlowe@gmail.com>)
Ответы Re: Two identical systems, radically different performance
Список pgsql-performance
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.

[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 по дате отправления:

Предыдущее
От: "Sam Wong"
Дата:
Сообщение: Re: LIKE op with B-Tree Index?
Следующее
От: "Albe Laurenz"
Дата:
Сообщение: Re: LIKE op with B-Tree Index?