Re: Performance Tuning Document? - Mailing list pgsql-general

From Steve Wolfe
Subject Re: Performance Tuning Document?
Date
Msg-id 004001c1d67c$c12c9de0$d281f6cc@iboats.com
Whole thread Raw
In response to Performance Tuning Document?  (Matthew Kirkwood <matthew@hairy.beasts.org>)
Responses Re: Performance Tuning Document?
List pgsql-general
> I'm playing with OSDB (http://osdb.sf.net/) and trying to get
> the best numbers possible out of it.
>
> I haven't been able to find anything resembling a performance
> tuning document.  Does such a thing exist?

  Unfortunately, not in any complete sense.

  There are a few guides from Bruce that make a good effort, but there
seems to be a *lot* of other information that can only be gleaned by
either being a developper or following the list very closely for a few
years.  Bruce's hardware tuning guide also doesn't really give any sorts
of guidelines or numbers to start from, it merely explains concepts and
leaves the investigation and twiddling to you.

> Under the "crossSectionTests(Mixed IR)" part of an OSDB run, a
> large number of shared_buffers causes severe slowdown on one of
> the tests -- it goes from a little over 200 seconds to nearly
> 2000.  I suspect internal lock contention, or maybe it's just
> that the read() path in Linux is quicker than PG's own cache?
>
> Any tips and tricks available?

  Yes.  Huge, raging amounts of shared buffers do have the consequence of
diminishing your disk cache size.  You want to make sure that you can
always keep the *entire* database in disk cache, or you end up taking a
performance hit by having to read from disk, in the same spirit of keeping
your machine from swapping.

Steve




pgsql-general by date:

Previous
From: Marcelo Pereira
Date:
Subject: Sum
Next
From: Philip Hallstrom
Date:
Subject: Re: Sum