Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id BAA3B1337B94 for ; Fri, 26 Nov 2010 18:30:26 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 06351-01 for ; Fri, 26 Nov 2010 22:30:19 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mail.postgresql.org (Postfix) with ESMTP id 317D41337B53 for ; Fri, 26 Nov 2010 18:30:19 -0400 (AST) Received: from [192.168.1.6] (static-71-179-240-8.bltmmd.fios.verizon.net [71.179.240.8]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0McxrW-1P589b2DXW-00IXzJ; Fri, 26 Nov 2010 23:30:18 +0100 Message-ID: <4CF034F8.5080606@2ndquadrant.com> Date: Fri, 26 Nov 2010 17:30:16 -0500 From: Greg Smith User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: "Christian Elmerot @ One.com" CC: pgsql-performance@postgresql.org Subject: Re: CPUs for new databases References: <4CC6CFAA.10107@one.com> <4CC73FEF.9020805@agliodbs.com> <4CC88476.7010804@2ndquadrant.com> <4CEFE29B.7040408@one.com> In-Reply-To: <4CEFE29B.7040408@one.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:BmWlPTNzcgFzFJrx1djJFowZbhZh1EZD3egD2tA+zTT XWm3HbFqCQ5OQrfMzlGuqABBgfQBbPcawvZ9dDpOUItZo2/u/7 sp2Do6DYPn8KoAwyyHZB271GxUGVMHVT8ocKx1yw4FzG5YCofY 4c//yjcvkNBgv0rYib970vRz9NHE+fuUze1zh6bkdW21ynQ2mK SNK8Kz3FFuUlCACSAj6Syn6l1JF1HKPUvZUCbW1rzs= X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201011/386 X-Sequence-Number: 41410 Christian Elmerot @ One.com wrote: > Highest results comes at 32 threads: > Number of Threads requested = 32 > Function Rate (MB/s) Avg time Min time Max time > Triad: 81013.5506 0.0378 0.0377 0.0379 There is some run-to-run variation in the results of this test, and accordingly some margin for error in each individual result. I wouldn't consider the difference between the speed at 32 threads (81) and 48 (79.7) to be statistically significant, and based on the overall shape of the results curve that 32 result looks suspicious. I would bet that if you run the test multiple times, you'd sometimes seen the 48 core one run faster than the 32. > The pattern is quite clear in that any multiple of 4 (the number of > physical CPU packages) get a higher value but thinking about how the > memory is connected and utilized this makes perfect sense. In addition to the memory issues, there's also thread CPU scheduling involved here. Ideally the benchmark would pin each thread to a single core and keep it there for the runtime of the test, but it's not there yet. I suspect one source of variation at odd numbers of threads involves processes that bounce between CPUs more than in the more even cases. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services and Support www.2ndQuadrant.us "PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books