Received: from makus.postgresql.org ([98.129.198.125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TOk2j-000397-Uc for pgsql-performance@postgresql.org; Thu, 18 Oct 2012 06:57:22 +0000 Received: from host36.ns3.it ([80.79.54.36] helo=mail.opinioni.net) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TOk2e-0005ey-Ib for pgsql-performance@postgresql.org; Thu, 18 Oct 2012 06:57:21 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.opinioni.net (Postfix) with ESMTP id EB1EF4E275B; Thu, 18 Oct 2012 09:00:11 +0200 (CEST) Received: from mail.opinioni.net ([127.0.0.1]) by localhost (opinioni.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbWq-7xuScb9; Thu, 18 Oct 2012 09:00:11 +0200 (CEST) Received: from [192.168.1.50] (78-134-6-72.v4.ngi.it [78.134.6.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.opinioni.net (Postfix) with ESMTPS id 8CEDE4E5599; Thu, 18 Oct 2012 09:00:11 +0200 (CEST) Message-ID: <507FA848.7040801@opinioni.net> Date: Thu, 18 Oct 2012 08:57:12 +0200 From: Andrea Suisani User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Scott Marlowe CC: Claudio Freire , Craig James , pgsql-performance@postgresql.org Subject: Re: Two identical systems, radically different performance References: <5076D433.7090605@opinioni.net> <5076DA4E.80504@opinioni.net> <507BC8DE.9050109@opinioni.net> <507C2ACA.3020503@opinioni.net> <507ED293.6010803@opinioni.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201210/241 X-Sequence-Number: 48200 On 10/17/2012 06:35 PM, Scott Marlowe wrote: > On Wed, Oct 17, 2012 at 9:45 AM, Andrea Suisani 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