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
>
