X-Original-To: pgsql-performance-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 4CB109FA65C for ; Wed, 21 Jun 2006 13:39:40 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 16911-10 for ; Wed, 21 Jun 2006 13:39:34 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from q1exch01.Q1LABS.INC (Q1EXCH01.Q1Labs.com [205.174.165.4]) by postgresql.org (Postfix) with ESMTP id EC8B09F9CC1 for ; Wed, 21 Jun 2006 13:39:33 -0300 (ADT) Received: from q1exch02.Q1LABS.INC ([10.100.50.8]) by q1exch01.Q1LABS.INC with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 13:39:33 -0300 X-PMWin-Version: 2.5.0e, Antispam-Engine: 2.3.0.1, Antivirus-Engine: 2.34.3 thread-index: AcaVUUYvS38GLVVeQqqAk9IvMH7y5Q== Received: from [10.100.100.123] ([10.100.100.123]) by q1exch02.Q1LABS.INC with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 13:39:32 -0300 From: "jody brownell" To: "Csaba Nagy" Subject: Re: Help tuning autovacuum - seeing lots of relationbloat Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2663 Date: Wed, 21 Jun 2006 13:39:33 -0300 User-Agent: KMail/1.8.3 Cc: "postgres performance list" References: <200606211052.43227.jody.brownell@q1labs.com> <200606211321.06253.jody.brownell@q1labs.com> <1150907799.3309.53.camel@coppola.muc.ecircle.de> In-Reply-To: <1150907799.3309.53.camel@coppola.muc.ecircle.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <200606211339.33262.jody.brownell@q1labs.com> X-OriginalArrivalTime: 21 Jun 2006 16:39:32.0889 (UTC) FILETIME=[462D2090:01C69551] X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200606/406 X-Sequence-Number: 19763 that is exactly what I am seeing, one process, no change, always in idle while the others are constantly changing their state. looks like someone opened a tx then is blocking on a queue lock or something. dang. On Wednesday 21 June 2006 13:36, Csaba Nagy wrote: > On Wed, 2006-06-21 at 18:21, jody brownell wrote: > > That is interesting. > > > > There is one thread keeping a transaction open it appears from ps > > > > postgres: app app xxx(42644) idle in transaction > > That shouldn't be a problem on itself, "idle in transaction" happens all > the time between 2 commands in the same transaction... you only have a > problem if you see the same PID always "idle", that means somebody left > an open transaction and left for lunch. > > [snip] > > this was with the "Idle in transaction" though..... > > This probably means you don't have long running transactions currently. > However, if you happen to have just one such long transaction, the dead > space accumulates and normal vacuum will not be able to clean that > anymore. But I guess if you didn't find one now then you should take a > look at Tom's suggestion and bump up debug level to see if autovacuum > picks your table at all... > > > Ah HA! Wondering, my autovacuum naptime is 60 seconds, that is also the interval which I wake up and begin persistence. > > Wondering if I am simply locking autovacuum out of the tables b/c they are on a similar timeline. > > > > I will try a 30 second naptime, if this is it, that should increase the likely hood of falling on the right side of the TX more often. > > > > make sense? > > I don't think that's your problem... vacuum wouldn't be locked out by > any activity which doesn't lock exclusively the table (and I guess > you're not doing that). If your persistence finishes quickly then that's > not the problem. > > Oh, just occured to me... in order to use autovacuum you also need to > enable the statistics collector on row level: > > stats_start_collector = on > stats_row_level = on > > See also: > http://www.postgresql.org/docs/8.1/static/maintenance.html#AUTOVACUUM > > This was not mentioned in the settings in your original post, so I guess > you didn't touch that, and I think they are disabled by default. > > If this is disabled, you should enable it and "pg_ctl reload ....", that > should fix the problem. > > Cheers, > Csaba. > > >