From: Jaime Casanova <jcasanov@systemguards.com.ec>
To: Robert Haas <robertmhaas@gmail.com>
Cc: psql performance list <pgsql-performance@postgresql.org>
Subject: Re: measure database contention
Date: Wed, 17 Dec 2008 10:38:29 -0500
Message-ID: <3073cc9b0812170738v69e43d89r8d6dae87453b4993@mail.gmail.com> (raw)
In-Reply-To: <603c8f070812170618g3116a90du94cbf102f0336d59@mail.gmail.com>
References: <3073cc9b0812161132w3ae157a8n69e2b0cccea05ca2@mail.gmail.com>
<603c8f070812170618g3116a90du94cbf102f0336d59@mail.gmail.com>
On Wed, Dec 17, 2008 at 9:18 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Dec 16, 2008 at 2:32 PM, Jaime Casanova
> <jcasanov@systemguards.com.ec> wrote:
>> we have a some bad queries (developers are working on that), some of
>> them run in 17 secs and that is the average but when analyzing logs i
>> found that from time to time some of them took upto 3 mins (the same
>> query that normally runs in 17secs).
>>
>> so my question is: how could i look for contention problems?
>
> Is it the exact same query?
is the exact query... i think it will be removed later today because
is a bad query anyway... but my fear is that something like happens
even with good ones...
maybe chekpoints could be the problem?
i have 8.3.5 and condigured checkpoint_timeout in 15 minutes,
chekpoint_segments 6 and checkpoint_completion_target to 0.5
i'm putting log_checkpoints to on, but should be good if there is way
to analyze them better than looking through the log
> Sometimes you might find that the query
> plan changes depending on the particular values you have in there; it
> is worth running "EXPLAIN ANALYZE" to look for such cases.
>
don't think that could happen in this query, because there is no way
it will choose something better than seqscan
> You might also want to look at pg_locks.
>
Only Shared ones...
PS: more info about my system (sorry for don't giving it in the first post)
2 PROCESSORS Xeon(R) CPU E5430 @ 2.66GHz with 4 cores each
18Gb in Ram (4gb in shared_buffers, 4mb in work_mem)
the db size is 2gb (reported by pg_database_size)
max. concurrent connections seen until now: 256
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
AsesorÃa y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157
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: jcasanov@systemguards.com.ec, robertmhaas@gmail.com
Subject: Re: measure database contention
In-Reply-To: <3073cc9b0812170738v69e43d89r8d6dae87453b4993@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