Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1Ty8d5-0003oO-0J for pgsql-performance@arkaria.postgresql.org; Wed, 23 Jan 2013 22:17:11 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1Ty8d3-0002TM-Qv for pgsql-performance@arkaria.postgresql.org; Wed, 23 Jan 2013 22:17:09 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1Ty8d2-0002TG-QS for pgsql-performance@postgresql.org; Wed, 23 Jan 2013 22:17:08 +0000 Received: from mout.gmx.net ([74.208.4.200]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1Ty8d0-0005HQ-26 for pgsql-performance@postgresql.org; Wed, 23 Jan 2013 22:17:08 +0000 Received: from mailout-us.gmx.com ([172.19.198.47]) by mrigmx.server.lan (mrigmxus001) with ESMTP (Nemesis) id 0MWk7b-1UVsto3PLP-00XruJ for ; Wed, 23 Jan 2013 23:17:03 +0100 Received: (qmail 951 invoked by uid 0); 23 Jan 2013 22:17:03 -0000 Received: from 76.255.19.161 by rms-us019 with HTTP Content-Type: text/plain; charset="utf-8" Date: Wed, 23 Jan 2013 17:17:00 -0500 From: "Kevin Grittner" Message-ID: <20130123221700.119100@gmx.com> MIME-Version: 1.0 Subject: Re: autovacuum fringe case? To: "AJ Weber" ,pgsql-performance@postgresql.org X-Authenticated: #138763884 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: CwRyceJP3zOlOQ09LnwhqSd+IGRvb4AW X-Pg-Spam-Score: -2.6 (--) 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 AJ Weber wrote: > Is it possible that some spikes in IO could be attributable to > the autovacuum process? Is there a way to check this theory? Taking a look at the ps aux listing, pg_stat_activity, and pg_locks should help establish a cause, or at least rule out a number of possibilities. There is a known issue with autovacuum when it tries to reduce the size of a table which is found to be larger than it currently needs to be while other transactions try to access the table. This issue will be fixed in the next minor release for 9.0 and above. If this is the issue a manual VACUUM ANALYZE will fix things -- at least for a while. -Kevin -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance