From: Uwe Bartels <uwe.bartels@gmail.com>
To: Alexander Staubo <alex@bengler.no>
Cc: pgsql-performance@postgresql.org
Subject: Re: how to find the sql using most of the i/o in an oltp system
Date: Sun, 15 Jun 2008 16:41:25 +0200
Message-ID: <8ea917510806150741i1fb1a2dfhb3fe71eac2573dd1@mail.gmail.com> (raw)
In-Reply-To: <88daf38c0806150703s24f7736fuc88aded848186af4@mail.gmail.com>
References: <48551DB0.8050507@gmail.com>
<88daf38c0806150703s24f7736fuc88aded848186af4@mail.gmail.com>
Hi Alexander,
thanks for you answer.
What you wrote in terms of postgres I knew. I just tested to log all
statements with statistics. This is a lot of unstructured data in a logfile.
But this is the best I found as far.
The database is running on a solaris box. So DTrace is no problem. I
couldn't find any dtrace scripts for postgres. Do you know any scripts
except this sample script?
Thanks.
Uwe
On Sun, Jun 15, 2008 at 4:03 PM, Alexander Staubo <alex@bengler.no> wrote:
> On Sun, Jun 15, 2008 at 3:48 PM, Uwe Bartels <uwe.bartels@gmail.com>
> wrote:
> > Tuning a sql statements I'm familiar with. Finding a sql statement which
> > takes too long due to i/o is probably easy as well. But how about
> statements
> > that take about 100 ms, that read a lot and that are executed several
> times
> > per second?
>
> Take a look at the PostgreSQL manual chapter on monitoring and statistics:
>
> http://www.postgresql.org/docs/8.3/interactive/monitoring.html
>
> If you have access to DTrace (available on Solaris, OS X and possibly
> FreeBSD), you could hook the low-level system calls to reads and
> writes. If you don't have access to DTrace, the pg_statio_* set of
> tables is your main option. In particular, pg_statio_user_tables and
> pg_statio_user_indexes. See the documentation for the meaning of the
> individual columns.
>
> Unfortunately, the statistics tables are not transaction-specific
> (indeed I believe they only update once you commit the transaction,
> and then only after a delay), meaning they capture statistics about
> everything currently going on in the database. The only way to capture
> statistics about a single query, then, is to run it in complete
> isolation.
>
> Alexander.
>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: uwe.bartels@gmail.com, alex@bengler.no
Subject: Re: how to find the sql using most of the i/o in an oltp system
In-Reply-To: <8ea917510806150741i1fb1a2dfhb3fe71eac2573dd1@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
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