From: | Matthew Kirkwood <matthew(at)hairy(dot)beasts(dot)org> |
---|---|
To: | Steve Wolfe <steve(at)iboats(dot)com> |
Cc: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Performance Tuning Document? |
Date: | 2002-03-28 17:37:43 |
Message-ID: | Pine.LNX.4.33.0203281732400.11581-100000@sphinx.mythic-beasts.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, 28 Mar 2002, Steve Wolfe wrote:
> > 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.
Yep. Guess I have a few busy evenings and weekends ahead...
> > 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?
> 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.
I watched the run with "vmstat 1" and there was very close to
zero disk read activity (and no swapping). My test machine
has ~400Mb or RAM and the shared_buffers shouldn't have been
over 80Mb, so that makes sense to me.
I guess there's a linear list, a poor hash function, or some
heavy lock contention somewhere causing this.
Matthew.
From | Date | Subject | |
---|---|---|---|
Next Message | Jean-Luc Lachance | 2002-03-28 17:40:10 | Re: Sum |
Previous Message | Marcelo Pereira | 2002-03-28 17:29:52 | Re: Sum |