pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedPARSE WAITING
5+ messages / 2 participants
[nested] [flat]
* PARSE WAITING
@ 2010-08-23 22:15 David Kerr <dmk@mr-paradox.net>
2010-08-23 22:19 ` Re: PARSE WAITING David Kerr <dmk@mr-paradox.net>
2010-08-23 22:23 ` Re: PARSE WAITING Alvaro Herrera <alvherre@commandprompt.com>
0 siblings, 2 replies; 5+ messages in thread
From: David Kerr @ 2010-08-23 22:15 UTC (permalink / raw)
To: pgsql-performance
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
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: PARSE WAITING
2010-08-23 22:15 PARSE WAITING David Kerr <dmk@mr-paradox.net>
@ 2010-08-23 22:19 ` David Kerr <dmk@mr-paradox.net>
1 sibling, 0 replies; 5+ messages in thread
From: David Kerr @ 2010-08-23 22:19 UTC (permalink / raw)
To: pgsql-performance
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
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: PARSE WAITING
2010-08-23 22:15 PARSE WAITING David Kerr <dmk@mr-paradox.net>
@ 2010-08-23 22:23 ` Alvaro Herrera <alvherre@commandprompt.com>
2010-08-23 22:47 ` Re: PARSE WAITING David Kerr <dmk@mr-paradox.net>
1 sibling, 1 reply; 5+ messages in thread
From: Alvaro Herrera @ 2010-08-23 22:23 UTC (permalink / raw)
To: David Kerr <dmk@mr-paradox.net>; +Cc: pgsql-performance
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
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: PARSE WAITING
2010-08-23 22:15 PARSE WAITING David Kerr <dmk@mr-paradox.net>
2010-08-23 22:23 ` Re: PARSE WAITING Alvaro Herrera <alvherre@commandprompt.com>
@ 2010-08-23 22:47 ` David Kerr <dmk@mr-paradox.net>
2010-08-24 01:17 ` Re: PARSE WAITING Alvaro Herrera <alvherre@commandprompt.com>
0 siblings, 1 reply; 5+ messages in thread
From: David Kerr @ 2010-08-23 22:47 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@commandprompt.com>; +Cc: 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
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: PARSE WAITING
2010-08-23 22:15 PARSE WAITING David Kerr <dmk@mr-paradox.net>
2010-08-23 22:23 ` Re: PARSE WAITING Alvaro Herrera <alvherre@commandprompt.com>
2010-08-23 22:47 ` Re: PARSE WAITING David Kerr <dmk@mr-paradox.net>
@ 2010-08-24 01:17 ` Alvaro Herrera <alvherre@commandprompt.com>
0 siblings, 0 replies; 5+ messages in thread
From: Alvaro Herrera @ 2010-08-24 01:17 UTC (permalink / raw)
To: David Kerr <dmk@mr-paradox.net>; +Cc: pgsql-performance
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
^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2010-08-24 01:17 UTC | newest]
Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2010-08-23 22:15 PARSE WAITING David Kerr <dmk@mr-paradox.net>
2010-08-23 22:19 ` David Kerr <dmk@mr-paradox.net>
2010-08-23 22:23 ` Alvaro Herrera <alvherre@commandprompt.com>
2010-08-23 22:47 ` David Kerr <dmk@mr-paradox.net>
2010-08-24 01:17 ` Alvaro Herrera <alvherre@commandprompt.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox