X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 00B749DCB8C for ; Wed, 8 Mar 2006 23:23:36 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 38533-07 for ; Wed, 8 Mar 2006 23:23:39 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from noel.decibel.org (noel.decibel.org [67.100.216.10]) by postgresql.org (Postfix) with ESMTP id EC43E9DCB46 for ; Wed, 8 Mar 2006 23:23:32 -0400 (AST) Received: by noel.decibel.org (Postfix, from userid 1001) id 182385645D; Wed, 8 Mar 2006 21:23:38 -0600 (CST) Received: (hashcash-sendmail, from uid 1001); Wed, 8 Mar 2006 21:23:37 -0600 Date: Wed, 8 Mar 2006 21:23:37 -0600 From: "Jim C. Nasby" To: "mcelroy, tim" Cc: "'pgsql-performance@postgresql.org'" Subject: Re: pg_reset_stats + cache I/O % Message-ID: <20060309032337.GW45250@pervasive.com> References: <0C4841B42F87D51195BD00B0D020F5CB044B2431@morpheus.bostonstock.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0C4841B42F87D51195BD00B0D020F5CB044B2431@morpheus.bostonstock.com> X-Operating-System: FreeBSD 6.0-RELEASE-p4 amd64 X-Distributed: Join the Effort! http://www.distributed.net User-Agent: Mutt/1.5.11 X-Hashcash: 1:20:060309:tim.mcelroy@bostonstock.com::4PyoxPIxKm4yLz0G:0000000000 0000000000000000000000004Gaz X-Hashcash: 1:20:060309:pgsql-performance@postgresql.org::/HH955dTInJHvsFy:00000 0000000000000000000000001eRL X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.109 required=5 tests=[AWL=0.109] X-Spam-Score: 0.109 X-Spam-Level: X-Archive-Number: 200603/93 X-Sequence-Number: 17530 On Wed, Mar 08, 2006 at 01:35:35PM -0500, mcelroy, tim wrote: > I actually need this info as I was tasked by management to provide it. Not > sure if they understand that or not, I do but management does like to see > how well the system and its components are performing. Also, I would > utilize these results to test any cache tuning changes I may make. What I feared. While monitoring cache hit % over time isn't a bad idea, it's less than half the picture, which makes fertile ground for optimizing for some mythical target instead of actual system performance. If the "conclusion" from these numbers is that shared_buffers needs to get set larger than min(50000, 10% of memory) I'd very seriously re-consider how performance tuning is being done. But hopefully I'm just being paranoid and you guys are just doing a great job of monitoring things and keeping on the ball. :) -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461