Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id F2BD563289A for ; Mon, 23 Aug 2010 19:47:10 -0300 (ADT) 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 87556-01 for ; Mon, 23 Aug 2010 22:47:03 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from vexbert.mr-paradox.net (vexbert.mr-paradox.net [198.145.180.174]) by mail.postgresql.org (Postfix) with ESMTP id DBE2863275E for ; Mon, 23 Aug 2010 19:47:03 -0300 (ADT) Received: by vexbert.mr-paradox.net (Postfix, from userid 18391) id B4D00845EE; Mon, 23 Aug 2010 18:47:02 -0400 (EDT) Date: Mon, 23 Aug 2010 15:47:02 -0700 From: David Kerr To: Alvaro Herrera Cc: pgsql-performance Subject: Re: PARSE WAITING Message-ID: <20100823224702.GA83252@mr-paradox.net> References: <20100823221556.GC79389@mr-paradox.net> <1282602153-sup-6272@alvh.no-ip.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1282602153-sup-6272@alvh.no-ip.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-10 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201008/272 X-Sequence-Number: 40115 On Mon, Aug 23, 2010 at 06:23:25PM -0400, Alvaro Herrera wrote: - Excerpts from David Kerr's message of lun ago 23 18:15:56 -0400 2010: - > Howdy all, - > - > We're doing some performance testing, and when we scaled it our app up to about 250 concurrent users - > we started seeing a bunch of processes sititng in "PARSE WAITING" state. - > - > Can anyone give me insite on what this means? what's the parse waiting for? - - It means the parse phase is waiting for a lock. You can see exactly - what it's waiting for by looking at pg_locks "WHERE NOT GRANTED". - - Have you got lots of partitions, or something? no, the xlog directory filled up due to me being an idiot. once concern i have though, is that after i freed up space in the pg_xlog directory the processess didn't start moving again.. is that normal? this is 8.3.9) also, as a result i had to crash the DB.. it's now going through and doing this at startup: unlink("base/pgsql_tmp/pgsql_tmp28335.15779") = 0 unlink("base/pgsql_tmp/pgsql_tmp28335.25919") = 0 unlink("base/pgsql_tmp/pgsql_tmp28335.13352") = 0 unlink("base/pgsql_tmp/pgsql_tmp28335.16276") = 0 unlink("base/pgsql_tmp/pgsql_tmp28335.27857") = 0 unlink("base/pgsql_tmp/pgsql_tmp28335.34652") = 0 unlink("base/pgsql_tmp/pgsql_tmp28335.6804") = 0 unlink("base/pgsql_tmp/pgsql_tmp28335.4270") = 0 unlink("base/pgsql_tmp/pgsql_tmp28335.26926") = 0 unlink("base/pgsql_tmp/pgsql_tmp28335.29281") = 0 unlink("base/pgsql_tmp/pgsql_tmp28335.16689") = 0 unlink("base/pgsql_tmp/pgsql_tmp28335.36355") = 0 unlink("base/pgsql_tmp/pgsql_tmp28335.5502") = 0 unlink("base/pgsql_tmp/pgsql_tmp28335.5874") = 0 unlink("base/pgsql_tmp/pgsql_tmp28335.19594") = 0 unlink("base/pgsql_tmp/pgsql_tmp28335.11514") = 0 unlink("base/pgsql_tmp/pgsql_tmp28335.11865") = 0 unlink("base/pgsql_tmp/pgsql_tmp28335.20944") = 0 unlink("base/pgsql_tmp/pgsql_tmp28335.35733") = 0 unlink("base/pgsql_tmp/pgsql_tmp28335.8401") = 0 unlink("base/pgsql_tmp/pgsql_tmp28335.3767") = 0 unlink("base/pgsql_tmp/pgsql_tmp28335.2101") = 0 unlink("base/pgsql_tmp/pgsql_tmp28335.31776") = 0 unlink("base/pgsql_tmp/pgsql_tmp28335.15686") = 0 unlink("base/pgsql_tmp/pgsql_tmp28335.10364") = 0 unlink("base/pgsql_tmp/pgsql_tmp28335.12593") = 0 unlink("base/pgsql_tmp/pgsql_tmp28335.6041") = 0 unlink("base/pgsql_tmp/pgsql_tmp28335.3030") = 0 unlink("base/pgsql_tmp/pgsql_tmp28335.14737") = 0 which isn't the fastest operation.. just for my info, can anyone tell me what pgsql_tmp is, and why the engine is wacking each file individually? Thanks! Dave