Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 3F83D1337B34 for ; Wed, 16 Feb 2011 18:02:50 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 22903-04 for ; Wed, 16 Feb 2011 22:02:43 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by mail.postgresql.org (Postfix) with ESMTP id AB044133616B for ; Wed, 16 Feb 2011 18:02:42 -0400 (AST) Received: from [192.168.1.6] (mail.highperformancepostgresql.com [71.179.240.8]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0MWxmu-1PbW900IwW-00VztD; Wed, 16 Feb 2011 23:02:42 +0100 Message-ID: <4D5C4980.9070807@2ndquadrant.com> Date: Wed, 16 Feb 2011 17:02:40 -0500 From: Greg Smith User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Chris Hoover CC: PGSQL Performance Subject: Re: Estimating hot data size References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:EAtxbDVXYcSizSPv/PpmIpzJffs78rf08ZPpf4eQHyG HzCk3aa+UprI/HPqphnUwVgNN13A0MMevY1V2cQ+IOSJJIed0Y +Gzr9oRppk23Vh8eKKT+e6uZ59IG+FFUhdOJm8T7X/YIkQCYUh yUxiOBVCmyAGg4emM1/2U75CG84ZCKnCRQVVYxcQb6Cnm/SS5b MCFvL5XTHujkDy8CXv8uXw1HRr2lLPpZ8JselmcFoo= 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: 201102/421 X-Sequence-Number: 42559 Chris Hoover wrote: > Basically, I'm using the sum(heap_blks_read + idx_blks_read) from > pg_statio_all_tables, and diffing the numbers over a period of time (1 > hour at least). Is this a fair estimate? The reason for doing this > is we are looking at new server hardware, and I want to try and get > enough ram on the machine to keep the hot data in memory plus provide > room for growth. Those two are measuring reads to the operating system, which isn't really a good measure of the working data set. If you switch to the internal counters that measure what's already cached, that won't be quite right either. Those will be repeatedly measuring the same block, on the truly hot ones, which inflates how big you'll think the working set is relative to its true size. If you visit http://projects.2ndquadrant.com/talks you'll find a talk called "Inside the PostgreSQL Buffer Cache" that goes over how the cache is actually managed within the database. There's also some sample queries that run after you install the pg_buffercache module into a database. Check out "Buffer contents summary, with percentages". That's the only way to really measure what you're trying to see. I will sometimes set shared_buffers to a larger value than would normally be optimal for a bit, just to get a better reading on what the hot data is. If you also want to get an idea what's in the operating system cache, the pgfincore module from http://pgfoundry.org/projects/pgfincore/ will allow that on a Linux system. -- 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