Re: [Testperf-general] BufferSync and bgwriter

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: josh(at)agliodbs(dot)com, Jan Wieck <JanWieck(at)Yahoo(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Neil Conway <neilc(at)samurai(dot)com>, Zeugswetter Andreas DAZ SD <ZeugswetterA(at)spardat(dot)at>, Richard Huxton <dev(at)archonet(dot)com>, pgsql-hackers(at)postgresql(dot)org, testperf-general(at)pgfoundry(dot)org
Subject: Re: [Testperf-general] BufferSync and bgwriter
Date: 2004-12-18 20:52:39
Message-ID: 1103403159.2893.56.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 2004-12-16 at 17:54, Richard Huxton wrote:
> Josh Berkus wrote:
> >>Clearly, OSDL-DBT2 is not a real world test! That is its benefit, since
> >>it is heavily instrumented and we are able to re-run it many times
> >>without different parameter settings. The application is well known and
> >>doesn't suffer that badly from factors that would allow certain effects
> >>to be swamped. If it had too much randomness or variation, it would be
> >>difficult to interpret.
> >
> > I don't think you followed me. The issue is that for parameters designed to
> > "smooth out spikes" like bgwriter and vacuum delay, it helps to have really
> > bad spikes to begin with. There's a possibility that the parameters (and
> > calculations) that work well for for a "steady-state" OLTP application are
> > actually bad for an application with much more erratic usage, just as a high
> > sort_mem is good for DSS and bad for OLTP.
>
> I'm a little concerned that in an erratic, or even just a changing
> environment there isn't going to be any set of values that are "correct".

I think this expresses my own thoughts most clearly, however: There have
been many good ideas expressed on this thread, though none of them,
including my own, are IMHO suitable for inclusion in 8.0, given the
stage of the release process we are now at.

***
Please give your support now to the addition of Neil's recent bgwriter
patch to the 8.0 release. It simplifies tuning, is proven to remove a
clear performance blockage, yet does so without changing the underlying
algorithm used by the bgwriter - so there is no case to answer along the
lines that this might not apply in some situations. Neil's bgwriter does
the same thing, just avoids holding a critical lock for longer than it
needs to.
***

I will happily discuss further ideas for 8.1 at a later stage.

I'll be around tomorrow for further discussion and better replies to
different individual points. Please excuse my slow answers during this
debate.

--
Best Regards, Simon Riggs

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2004-12-18 21:24:49 Re: Port report: NetBSD 2.0 mac68k
Previous Message Rémi Zara 2004-12-18 18:49:48 Re: Port report: NetBSD 2.0 mac68k