Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id F033E1337BC8 for ; Mon, 9 May 2011 19:29:49 -0300 (ADT) 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 53751-02 for ; Mon, 9 May 2011 22:29:42 +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 5F2CA1337BD0 for ; Mon, 9 May 2011 19:29:42 -0300 (ADT) Received: from [192.168.1.6] (mail.highperformancepostgresql.com [71.179.240.8]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0M9LBa-1QRlu724wY-00D96i; Tue, 10 May 2011 00:29:41 +0200 Message-ID: <4DC86ACF.6050008@2ndQuadrant.com> Date: Mon, 09 May 2011 18:29:35 -0400 From: Greg Smith User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: Benchmarking a large server References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:sR9Zi7yBdhHMrAWEqqyNktCtgu0NI1rAnke/kYdPqul sPoF9ON3w7zdq3E4NlsvD5t43kFHJoi92kt3Pr7eraCxkM+xE4 JkmYylcXd5Gz6+UMNoIK2mWxQP9vnnpYSvU/iO8kZZHZKJYmiR tO1wSuNHq1MSN9DBUke/GCoyohokw0PFwbNfz7yRHUZiKFybVD WWpi1CAUZMWGBtvf4yn0cIhcmY09E7kxF+y5FOonnc= 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: 201105/99 X-Sequence-Number: 43608 On 05/09/2011 04:32 PM, Chris Hoover wrote: > So, does anyone have any suggestions/experiences in benchmarking > storage when the storage is smaller then 2x memory? If you do the Linux trick to drop its caches already mentioned, you can start a database test with zero information in memory. In that situation, whether or not everything could fit in RAM doesn't matter as much; you're starting with none of it in there. In that case, you can benchmark things without having twice as much disk space. You just have to recognize that the test become less useful the longer you run it, and measure the results accordingly. A test starting from that state will start out showing you random I/O speed on the device, slowing moving toward in-memory cached speeds as the benchmark runs for a while. You really need to capture the latency data for every transaction and graph it over time to make any sense of it. If you look at "Using and Abusing pgbench" at http://projects.2ndquadrant.com/talks , starting on P33 I have several slides showing such a test, done with pgbench and pgbench-tools. I added a quick hack to pgbench-tools around then to make it easier to run this specific type of test, but to my knowledge no one else has ever used it. (I've had talks about PostgreSQL in my yard that were better attended than that session, for which I blame Jonah Harris for doing a great talk in the room next door concurrent with it.) -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us "PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books