Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XKF5n-0001GE-SN for pgsql-performance@arkaria.postgresql.org; Wed, 20 Aug 2014 23:14:59 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1XKF5n-0004Yn-CH for pgsql-performance@arkaria.postgresql.org; Wed, 20 Aug 2014 23:14:59 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1XKF5m-0004Y1-Gr for pgsql-performance@postgresql.org; Wed, 20 Aug 2014 23:14:58 +0000 Received: from mail.catalyst.net.nz ([2404:130:0:10::40:0]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XKF5h-0007eo-9u for pgsql-performance@postgresql.org; Wed, 20 Aug 2014 23:14:57 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.catalyst.net.nz (Postfix) with ESMTP id 9655831DAC; Thu, 21 Aug 2014 11:14:47 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at catalyst.net.nz Received: from mail.catalyst.net.nz ([127.0.0.1]) by localhost (bertrand.catalyst.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id updnWON-NaUf; Thu, 21 Aug 2014 11:14:46 +1200 (NZST) Received: from [IPv6:2404:130:0:1000:78b2:5349:e07d:5353] (unknown [IPv6:2404:130:0:1000:78b2:5349:e07d:5353]) (Authenticated sender: mark.kirkwood) by mail.catalyst.net.nz (Postfix) with ESMTPSA id BAC5A31D13; Thu, 21 Aug 2014 11:14:46 +1200 (NZST) Message-ID: <53F52BE6.6080006@catalyst.net.nz> Date: Thu, 21 Aug 2014 11:14:46 +1200 From: Mark Kirkwood User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Josh Berkus , pgsql-performance@postgresql.org CC: "Graeme B. Bell" Subject: Re: Turn off Hyperthreading! WAS: 60 core performance with 9.3 References: <53ACB190.2030206@catalyst.net.nz> <53ECFD75.3060408@agliodbs.com> <53ED371D.109@catalyst.net.nz> <53F4F36E.6050003@agliodbs.com> In-Reply-To: <53F4F36E.6050003@agliodbs.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org On 21/08/14 07:13, Josh Berkus wrote: > Mark, all: > > So, this is pretty damming: > > Read-only test with HT ON: > > [pgtest@db ~]$ pgbench -c 20 -j 4 -T 600 -S bench > starting vacuum...end. > transaction type: SELECT only > scaling factor: 30 > query mode: simple > number of clients: 20 > number of threads: 4 > duration: 600 s > number of transactions actually processed: 47167533 > tps = 78612.471802 (including connections establishing) > tps = 78614.604352 (excluding connections establishing) > > Read-only test with HT Off: > > [pgtest@db ~]$ pgbench -c 20 -j 4 -T 600 -S bench > starting vacuum...end. > transaction type: SELECT only > scaling factor: 30 > query mode: simple > number of clients: 20 > number of threads: 4 > duration: 600 s > number of transactions actually processed: 82457739 > tps = 137429.508196 (including connections establishing) > tps = 137432.893796 (excluding connections establishing) > > > On a read-write test, it's 10% faster with HT off as well. > > Further, from their production machine we've seen that having HT on > causes the machine to slow down by 5X whenever you get more than 40 > cores (as in 100% of real cores or 50% of HT cores) worth of activity. > > So we're definitely back to "If you're using PostgreSQL, turn off > Hyperthreading". > Hmm - that is interesting - I don't think we compared read only scaling for hyperthreading on and off (only read write). You didn't mention what cpu this is for (or how many sockets etc), would be useful to know. Notwithstanding the above results, my workmate Matt made an interesting observation: the scaling graph for (our) 60 core box (HT off), looks just like the one for our 32 core box with HT *on*. We are wondering if a lot of the previous analysis of HT performance regressions should actually be reevaluated in the light of ...err is it just that we have a lot more cores...? [1] Regards Mark [1] Particularly as in *some* cases (single socket i7 for instance) HT on seems to scale fine. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance