From: Jerry Champlin <jchamplin@absolute-performance.com>
To: Mark Kirkwood <markir@paradise.net.nz>
Cc: Scott Marlowe <scott.marlowe@gmail.com>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: Raid 10 chunksize
Date: Wed, 25 Mar 2009 04:05:40 -0600
Message-ID: <49CA01F4.8040009@absolute-performance.com> (raw)
In-Reply-To: <49C9A314.6050302@paradise.net.nz>
References: <49C98433.5080709@paradise.net.nz>
<dcc563d10903241911p29f604vfd9025a106d0eac3@mail.gmail.com>
<49C9A314.6050302@paradise.net.nz>
It sounds to me like you need to tune everything you can related to
postgresql, but it will unlikely be enough as your load continues to
increase. You might want to look into moving some of the read activity
off of the database. Depending on you application, memcached or ehcache
could help. You could also look at using something like Tokyo Cabinet
as a short term front end data store. Without understanding the
application architecture, I can't offer much in way of a specific
suggestion.
-Jerry
Jerry Champlin
Absolute Performance Inc.
Mark Kirkwood wrote:
> Scott Marlowe wrote:
>> On Tue, Mar 24, 2009 at 7:09 PM, Mark Kirkwood
>> <markir@paradise.net.nz> wrote:
>>
>>> I'm trying to pin down some performance issues with a machine where
>>> I work,
>>> we are seeing (read only) query response times blow out by an order of
>>> magnitude or more at busy times. Initially we blamed autovacuum, but
>>> after a
>>> tweak of the cost_delay it is *not* the problem. Then I looked at
>>> checkpoints... and altho there was some correlation with them and
>>> the query
>>> response - I'm thinking that the raid chunksize may well be the issue.
>>>
>>
>> Sounds to me like you're mostly just running out of bandwidth on your
>> RAID array. Whether or not you can tune it to run faster is the real
>> issue. This problem becomes worse as you add clients and the RAID
>> array starts to thrash. Thrashing is likely to be worse with a small
>> chunk size, so that's definitely worth a look at fixing.
>>
>>
>
> Yeah, I was wondering if we are maxing out the bandwidth...
>>> Fortunately there is an identical DR box, so I could do a little
>>> testing.
>>>
>>
>> Can you try changing the chunksize on the test box you're testing on
>> to see if that helps?
>>
>>
>
> Yes - or I am hoping to anyway (part of posting here was to collect
> some outside validation for the idea). Thanks for your input!
>
>
> Cheers
>
> Mark
>
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: jchamplin@absolute-performance.com, markir@paradise.net.nz, scott.marlowe@gmail.com
Subject: Re: Raid 10 chunksize
In-Reply-To: <49CA01F4.8040009@absolute-performance.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