Re: Re: [Testperf-general] BufferSync and bgwriter - Mailing list pgsql-hackers

From
Subject Re: Re: [Testperf-general] BufferSync and bgwriter
Date
Msg-id 28292295$110313307141c0798f455f79.76051458@config22.schlund.de
Whole thread Raw
Responses Re: [Testperf-general] BufferSync and bgwriter
List pgsql-hackers
Josh Berkus <josh@agliodbs.com> wrote on 15.12.2004, 18:36:53:
> Hmmm, I've not seen this.  For example, with people who are having trouble
> with checkpoint spikes on Linux, I've taken to recommending that they call
> sync() (via cron) every 5-10 seconds (thanks, Bruce, for suggestion!).
> Believe it or not, this does help smooth out the spikes and give better
> overall performance in a many-small-writes situation.

Yes, but bgwriter needs to issue the writes first before the kernel
cache can be flushed, which is the activity I've been focusing on. If
the bgwriter isn't writing enough, flushing the cache is pointless. If
the bgwriter is writing too much, then thats a waste and likely causing
buffer list contention.

> Simon, one of the problems with the OSDL-DBT2 test is that it's too steady.
> DBT2 gives a constant stream of small writes at a regular, predictable rate.
> This does not, in fact, match any real-world application I know.

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.

My goal has been to tune the server, not to derive marketing numbers.
What DBT-2 does reveal is where contention occurs within the PostgreSQL
server. If things are bad in a static, well known workload then they
will be much more erratic in the choppy waters of the real world.
Simulating reality isn't what any of us need to do - there's always a
system to look at and be confused by its peaks and troughs, user
complaints and hardware idiosyncracies.

DBT2 is just one workload amongst many you can choose as your "tuning
goal". The investigations on that have, IMHO, been genuinely useful in
discovering performance problems in the server. Mark's efforts to
improve the instrumentation of the tests will be useful on other
workloads also.

I'd encourage you to develop variations of DBT2 that can also be used to
tune the server, hopefully running on OSDL. I support open testing
methods as much as I support open development methods and projects.

DBT3 next...

Best Regards, Simon Riggs


pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: [Testperf-general] BufferSync and bgwriter
Next
From: Josh Berkus
Date:
Subject: Re: [Testperf-general] BufferSync and bgwriter