Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XpSno-0004MY-Bi for pgsql-performance@arkaria.postgresql.org; Sat, 15 Nov 2014 02:09:28 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1XpSnn-0002f1-T7 for pgsql-performance@arkaria.postgresql.org; Sat, 15 Nov 2014 02:09:27 +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 1XpSnm-0002eu-Pt for pgsql-performance@postgresql.org; Sat, 15 Nov 2014 02:09:26 +0000 Received: from mail-by2on0676.outbound.protection.outlook.com ([2a01:111:f400:fc0c::676] helo=na01-by2-obe.outbound.protection.outlook.com) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XpSnZ-0007qc-Dj for pgsql-performance@postgresql.org; Sat, 15 Nov 2014 02:09:25 +0000 Received: from decina.local (24.55.12.91) by DM2PR11MB0189.namprd11.prod.outlook.com (25.160.132.16) with Microsoft SMTP Server (TLS) id 15.1.16.15; Sat, 15 Nov 2014 02:09:05 +0000 Message-ID: <5466B5BB.8000208@BlueTreble.com> Date: Fri, 14 Nov 2014 20:08:59 -0600 From: Jim Nasby User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Mark Kirkwood , Shaun Thomas , 'Alexey Vasiliev' CC: 'Josh Berkus' , "pgsql-performance@postgresql.org" Subject: Re: pgtune + configurations with 9.3 References: <1415975036.62330340@f358.i.mail.ru> <0683F5F5A5C7FE419A752A034B4A0B9797DCD287@sswchi5pmbx2.peak6.net> <1415983219.686386092@f34.i.mail.ru> <0683F5F5A5C7FE419A752A034B4A0B9797DCD4DA@sswchi5pmbx2.peak6.net> <5466898C.9070809@catalyst.net.nz> In-Reply-To: <5466898C.9070809@catalyst.net.nz> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [24.55.12.91] X-ClientProxiedBy: BY1PR00CA0027.namprd00.prod.outlook.com (25.160.102.37) To DM2PR11MB0189.namprd11.prod.outlook.com (25.160.132.16) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR11MB0189; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR11MB0189; X-Forefront-PRVS: 03965EFC76 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(479174003)(24454002)(377454003)(51704005)(189002)(199003)(87976001)(36756003)(93886004)(20776003)(97736003)(23746002)(21056001)(50466002)(99396003)(64126003)(122386002)(59896002)(95666004)(107046002)(105586002)(106356001)(65816999)(120916001)(47776003)(76176999)(40100003)(15975445006)(64706001)(19580395003)(86362001)(15202345003)(42186005)(101416001)(62966003)(92726001)(66066001)(46102003)(50986999)(33656002)(83506001)(102836001)(65956001)(87266999)(77156002)(54356999)(4396001)(80316001)(77096003)(65806001)(85282002)(336755003)(18886065003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR11MB0189; H:decina.local; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR11MB0189; X-OriginatorOrg: bluetreble.com X-Pg-Spam-Score: -1.9 (-) 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 11/14/14, 5:00 PM, Mark Kirkwood wrote: > > as the 'rule of thumb' for setting shared_buffers. However I was recently benchmarking a machine with a lot of ram (1TB) and entirely SSD storage [1], and that seemed quite happy with 50GB of shared buffers (better performance than with 8GB). Now shared_buffers was not the variable we were concentrating on so I didn't get too carried away and try much bigger than about 100GB - but this seems like a good thing to come out with some numbers for i.e pgbench read write and read only tps vs shared_buffers 1 -> 100 GB in size. What PG version? One of the huge issues with large shared_buffers is the immense overhead you end up with for running the clock sweep, and on most systems that overhead is born by every backend individually. You will only see that overhead if your database is larger than shared bufers, because you only pay it when you need to evict a buffer. I suspect you'd actually need a database at least 2x > shared_buffers for it to really start showing up. > [1] I may be in a position to benchmark the machines these replaced at some not to distant time. These are the previous generation (0.5TB ram, 32 cores and all SSD storage) but probably still good for this test. Awesome! If there's possibility of developers getting direct access, I suspect folks on -hackers would be interested. If not but you're willing to run tests for folks, they'd still be interested. :) -- Jim Nasby, Data Architect, Blue Treble Consulting Data in Trouble? Get it in Treble! http://BlueTreble.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance