Skip site navigation (1) Skip section navigation (2)

Re: PARSE WAITING

From: David Kerr <dmk(at)mr-paradox(dot)net>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: pgsql-performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: PARSE WAITING
Date: 2010-08-23 22:47:02
Message-ID: 20100823224702.GA83252@mr-paradox.net (view raw or flat)
Thread:
Lists: pgsql-performance
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

In response to

Responses

pgsql-performance by date

Next:From: Alvaro HerreraDate: 2010-08-24 01:17:35
Subject: Re: PARSE WAITING
Previous:From: Alvaro HerreraDate: 2010-08-23 22:23:25
Subject: Re: PARSE WAITING

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group