From: PFC <lists@peufeu.com>
To: Thomas Spreng <spreng@socket.ch>
Cc: pgsql-performance@postgresql.org
Subject: Re: Oddly slow queries
Date: Wed, 16 Apr 2008 10:21:38 +0200
Message-ID: <op.t9o2uca7cigqcu@apollo13.peufeu.com> (raw)
In-Reply-To: <AE4F81FF-C8BE-44BC-A79D-48EC5BF20162@socket.ch>
References: <3D7728ED-3D36-47E6-9266-351073ED4E11@socket.ch>
<op.t9odybcgcigqcu@apollo13.peufeu.com>
<AE4F81FF-C8BE-44BC-A79D-48EC5BF20162@socket.ch>
On Wed, 16 Apr 2008 06:07:04 +0200, Thomas Spreng <spreng@socket.ch> wrote:
>
> On 16.04.2008, at 01:24, PFC wrote:
>>
>>> The queries in question (select's) occasionally take up to 5 mins even
>>> if they take ~2-3 sec under "normal" conditions, there are no
>>> sequencial scans done in those queries. There are not many users
>>> connected (around 3, maybe) to this database usually since it's still
>>> in a testing phase. I tried to hunt down the problem by playing around
>>> with resource usage cfg options but it didn't really made a difference.
>>
>> Could that be caused by a CHECKPOINT ?
>
>
> actually there are a few log (around 12 per day) entries concerning
> checkpoints:
>
> LOG: checkpoints are occurring too frequently (10 seconds apart)
> HINT: Consider increasing the configuration parameter
> "checkpoint_segments".
>
> But wouldn't that only affect write performance? The main problems I'm
> concerned about affect SELECT queries.
OK, so if you get 12 of those per day, this means your checkpoint
interval isn't set to 10 seconds... I hope...
Those probably correspond to some large update or insert query that comes
from a cron or archive job ?... or a developer doing tests or filling a
table...
So, if it is checkpointing every 10 seconds it means you have a pretty
high write load at that time ; and having to checkpoint and flush the
dirty pages makes it worse, so it is possible that your disk(s) choke on
writes, also killing the selects in the process.
-> Set your checkpoint log segments to a much higher value
-> Set your checkpoint timeout to a higher value (5 minutes or
something), to be tuned afterwards
-> Tune bgwriter settings to taste (this means you need a realistic load,
not a test load)
-> Use separate disk(s) for the xlog
-> For the love of God, don't keep the RAID5 for production !
(RAID5 + 1 small write = N reads + N writes, N=3 in your case)
Since this is a test server I would suggest RAID1 for the OS and database
files and the third disk for the xlog, if it dies you just recreate the
DB...
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: lists@peufeu.com, spreng@socket.ch
Subject: Re: Oddly slow queries
In-Reply-To: <op.t9o2uca7cigqcu@apollo13.peufeu.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