Postgres Pro
Downloads
Home   >   mailing lists

Thread: PARSE WAITING

PARSE WAITING

From
David Kerr
Date:
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?

Thanks

Dave

Re: PARSE WAITING

From
David Kerr
Date:
probably waiting on the xlog directory that's filled up... <sigh>
<shotgun>-><foot>->blamo

move along, nothing to see here =)


Dave


On Mon, Aug 23, 2010 at 03:15:56PM -0700, David Kerr wrote:
- 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?
-
- Thanks
-
- Dave
-
- --
- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
- To make changes to your subscription:
- http://www.postgresql.org/mailpref/pgsql-performance

Re: PARSE WAITING

From
Alvaro Herrera
Date:
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?

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Re: PARSE WAITING

From
David Kerr
Date:
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

Re: PARSE WAITING

From
Alvaro Herrera
Date:
Excerpts from David Kerr's message of lun ago 23 18:47:02 -0400 2010:

> 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?

These are temp files, which you can remove without concern if the server
is down.

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support