pg.ddx.io pgsql-sql@postgresql.org mailing list archive
help / color / mirror / Atom feedProfiling tool for postgres under win32
5+ messages / 3 participants
[nested] [flat]
* Profiling tool for postgres under win32
@ 2009-11-26 09:48 aymen marouani <marouani.aymen@gmail.com>
0 siblings, 2 replies; 5+ messages in thread
From: aymen marouani @ 2009-11-26 09:48 UTC (permalink / raw)
To: pgsql-sql
Hi,
I'm using the Postgres database system version 8.3 for a J2EE application.
I'd like to profile and monitor in "real time" the status of my queries
because I notice some slow loading.
Can anyone tell how to get a "good" profiling tool for the Postgres database
system ?
Thanks in advance.
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Profiling tool for postgres under win32
@ 2009-11-26 10:05 A. Kretschmer <andreas.kretschmer@schollglas.com>
parent: aymen marouani <marouani.aymen@gmail.com>
1 sibling, 0 replies; 5+ messages in thread
From: A. Kretschmer @ 2009-11-26 10:05 UTC (permalink / raw)
To: pgsql-sql
In response to aymen marouani :
> Hi,
> I'm using the Postgres database system version 8.3 for a J2EE application.
> I'd like to profile and monitor in "real time" the status of my queries
> because I notice some slow loading.
> Can anyone tell how to get a "good" profiling tool for the Postgres database
> system ?
Set log_min_duration to a propper value and analyse your slow queries.
Andreas
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header)
GnuPG: 0x31720C99, 1006 CCB4 A326 1D42 6431 2EB0 389D 1DC2 3172 0C99
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Profiling tool for postgres under win32
@ 2009-11-26 12:05 Craig Ringer <craig@postnewspapers.com.au>
parent: aymen marouani <marouani.aymen@gmail.com>
1 sibling, 1 reply; 5+ messages in thread
From: Craig Ringer @ 2009-11-26 12:05 UTC (permalink / raw)
To: aymen marouani <marouani.aymen@gmail.com>; +Cc: pgsql-sql
On 26/11/2009 5:48 PM, aymen marouani wrote:
> Hi,
> I'm using the Postgres database system version 8.3 for a J2EE application.
> I'd like to profile and monitor in "real time" the status of my queries
> because I notice some slow loading.
> Can anyone tell how to get a "good" profiling tool for the Postgres
> database system ?
I'm not aware of any tools that connect to the database to provide
profiling and monitoring.
What the right course of action is depends on what sort of slowdown
you're encountering. If it's particular activities within the program
that're a problem, then you should probably use logging in your
application to record database activity (including query runtimes) to
see what exactly it's doing.
If it's unpredictable slowdowns in operations that are normally fast,
then you need to look at the database end. Look into locking issues (
see: pg_catalog.pg_locks ), table bloat and VACUUM / autovacuum, and the
possibility of simple concurrent load spikes ( see
pg_catalog.pg_stat_activity ).
Typically what you'll do if you're seeing unpredictably slow queries is
use log_min_duration to log problem statements to the PostgreSQL log,
which you can then analyse. If you enable CSV logging, you can pull the
PostgreSQL log into a database, spreadsheet, or whatever for easier
analysis.
The new auto_explain module in 8.4 is excellent and very helpful too,
since it can help you find out what plans were used to execute problem
queries easily and conveniently.
Of course, this won't help you much if your problem is an application
issuing *huge* numbers of very small queries. You can set Pg to log
every query, but you'll rapidly have an apalling amount of data to troll
through, and it's hard to know which ones are related to user-perceived
slowdowns. Application logging is usually a better option for tracking
this sort of thing down.
Out of interest, how are you talking to PostgreSQL? Hand-written SQL via
JDBC? Hibernate / TopLink / some other ORM (possibly via JPA)?
If you're using Hibernate, just enable its query logging features via
log4j and watch what happens.
--
Craig Ringer
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Profiling tool for postgres under win32
@ 2009-11-30 08:42 aymen marouani <marouani.aymen@gmail.com>
parent: Craig Ringer <craig@postnewspapers.com.au>
0 siblings, 1 reply; 5+ messages in thread
From: aymen marouani @ 2009-11-30 08:42 UTC (permalink / raw)
To: Craig Ringer <craig@postnewspapers.com.au>; +Cc: pgsql-sql
Hi,
I'm sorry and thanks for the help, concerning your question :
"Out of interest, how are you talking to PostgreSQL? Hand-written SQL via
JDBC? Hibernate / TopLink / some other ORM (possibly via JPA)?"
I'm using JPA/Toplink to talk to the PostgresSQL, and I asked my question
about profiling because of a slow simple query
"SELECT i FROM Item i"
which takes 4s to execute.
Cordially and best regards.
2009/11/26 Craig Ringer <craig@postnewspapers.com.au>
> On 26/11/2009 5:48 PM, aymen marouani wrote:
> > Hi,
> > I'm using the Postgres database system version 8.3 for a J2EE
> application.
> > I'd like to profile and monitor in "real time" the status of my queries
> > because I notice some slow loading.
> > Can anyone tell how to get a "good" profiling tool for the Postgres
> > database system ?
>
> I'm not aware of any tools that connect to the database to provide
> profiling and monitoring.
>
> What the right course of action is depends on what sort of slowdown
> you're encountering. If it's particular activities within the program
> that're a problem, then you should probably use logging in your
> application to record database activity (including query runtimes) to
> see what exactly it's doing.
>
> If it's unpredictable slowdowns in operations that are normally fast,
> then you need to look at the database end. Look into locking issues (
> see: pg_catalog.pg_locks ), table bloat and VACUUM / autovacuum, and the
> possibility of simple concurrent load spikes ( see
> pg_catalog.pg_stat_activity ).
>
> Typically what you'll do if you're seeing unpredictably slow queries is
> use log_min_duration to log problem statements to the PostgreSQL log,
> which you can then analyse. If you enable CSV logging, you can pull the
> PostgreSQL log into a database, spreadsheet, or whatever for easier
> analysis.
>
> The new auto_explain module in 8.4 is excellent and very helpful too,
> since it can help you find out what plans were used to execute problem
> queries easily and conveniently.
>
> Of course, this won't help you much if your problem is an application
> issuing *huge* numbers of very small queries. You can set Pg to log
> every query, but you'll rapidly have an apalling amount of data to troll
> through, and it's hard to know which ones are related to user-perceived
> slowdowns. Application logging is usually a better option for tracking
> this sort of thing down.
>
> Out of interest, how are you talking to PostgreSQL? Hand-written SQL via
> JDBC? Hibernate / TopLink / some other ORM (possibly via JPA)?
>
> If you're using Hibernate, just enable its query logging features via
> log4j and watch what happens.
>
> --
> Craig Ringer
>
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Profiling tool for postgres under win32
@ 2009-11-30 09:00 Craig Ringer <craig@postnewspapers.com.au>
parent: aymen marouani <marouani.aymen@gmail.com>
0 siblings, 0 replies; 5+ messages in thread
From: Craig Ringer @ 2009-11-30 09:00 UTC (permalink / raw)
To: aymen marouani <marouani.aymen@gmail.com>; +Cc: pgsql-sql
On 30/11/2009 4:42 PM, aymen marouani wrote:
> Hi,
> I'm sorry and thanks for the help, concerning your question :
>
> "Out of interest, how are you talking to PostgreSQL? Hand-written SQL via
> JDBC? Hibernate / TopLink / some other ORM (possibly via JPA)?"
>
> I'm using JPA/Toplink to talk to the PostgresSQL, and I asked my
> question about profiling because of a slow simple query
>
> "SELECT i FROM Item i"
>
> which takes 4s to execute.
>
> Cordially and best regards.
In my off-list reply, where I suggested that you follow up on the list
instead, I pointed you to the EXPLAIN command. Also, the initial reply I
made pointed you to the logging options like log_min_duration.
You might want to use those tools to see what's going on. Start with:
EXPLAIN ANALYZE SELECT i FROM Item i;
... but I'd expect to see just a normal sequential scan of a table with
lots of entries. If that's the case, options to make it faster include:
- don't do it if you don't have to, it's always going to be expensive
- Make sure your tables aren't bloated. See:
http://www.postgresql.org/docs/8.3/interactive/routine-vacuuming.html
http://wiki.postgresql.org/wiki/Introduction_to_VACUUM%2C_ANALYZE%2C_EXPLAIN%2C_and_COUNT
... and use proper autovacuuming.
- Don't have tables that are too "wide", ie with too many fields. While
they're supported fine, they can be slower to scan because there's just
more data there. If you need crazy-fast sequential scans of the whole
table for just a few points of data, consider splitting the table into
two tables with a one-to-one relationship - but understand that that'll
slow other things down. A materialized view is another alternative.
- Write your app to deal with the latency. Sometimes queries are slow,
especially over slow links. Do your work in a background worker thread,
and keep the UI responsive. (Doesn't make sense for web apps, but is
important for normal GUI apps).
- Get faster disks, more RAM for caching, etc.
--
Craig Ringer
^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2009-11-30 09:00 UTC | newest]
Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2009-11-26 09:48 Profiling tool for postgres under win32 aymen marouani <marouani.aymen@gmail.com>
2009-11-26 10:05 ` A. Kretschmer <andreas.kretschmer@schollglas.com>
2009-11-26 12:05 ` Craig Ringer <craig@postnewspapers.com.au>
2009-11-30 08:42 ` aymen marouani <marouani.aymen@gmail.com>
2009-11-30 09:00 ` Craig Ringer <craig@postnewspapers.com.au>
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