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
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
Jan Wieck [EMAIL PROTECTED] writes:
Doesn't cranking up the bgwriter_percent to 100 effectively make the entire
shared memory a write-through cache? In other words, with 100% the bgwriter
will allways write all dirty blocks out and it becomes unlikely to avoid an IO
for subsequent
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
Josh Berkus wrote:
Simon,
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
On 12/12/2004 5:08 PM, Simon Riggs wrote:
On Sun, 2004-12-12 at 05:46, Neil Conway wrote:
Simon Riggs wrote:
If the bgwriter_percent = 100, then we should actually do the sensible
thing and prepare the list that we need, i.e. limit
StrategyDirtyBufferList to finding at most bgwriter_maxpages.
On 12/12/2004 9:43 PM, Neil Conway wrote:
On Sun, 2004-12-12 at 22:08 +, Simon Riggs wrote:
On Sun, 2004-12-12 at 05:46, Neil Conway wrote:
Is the plan to make bgwriter_percent = 100 the default setting?
Hmm...must confess that my only plan is:
i) discover dynamic behaviour of bgwriter
ii)
Josh Berkus [EMAIL PROTECTED] 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!).
Jan,
I too don't think that this approach will retain the checkpoing smooting
effect, the current implementation has.
The real problem is that the cleaner the buffer pool is, the longer
the scan for dirty buffers will take because the dirty blocks tend to be
at the very end of the scan
Folks,
To allow DBT2 to be used for real bgwriter benchmarking, Mark would need to
change the following:
1) Randomize the timing of the commits, so that sometimes there is only 30
writes/minute, and other times there is 300. A timing pattern that would
produce a sine wave with occasional
Simon,
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
Sorry for the delay; here are results with the bg3.patch with database
parameters that should match run 207. I haven't been able to take the
time too look over the results myself, but I tried to make sure this
run was the same as 207:
Sorry, wrong link, right one here:
http://www.osdl.org/projects/dbt2dev/results/dev4-010/211
Mark
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
On Wed, 2004-12-15 at 00:00, Mark Wong wrote:
http://www.osdl.org/projects/dbt2dev/results/dev4-010/211
Thanks Mark for turning that around so quickly. Looks good...
Results performed to compare
test 207
http://www.osdl.org/projects/dbt2dev/results/dev4-010/207
test 211 with bg3.patch
On Mon, 2004-12-13 at 04:39, Mark Kirkwood wrote:
I am seeing a reasonably reproducible performance boost after applying
your patch (I'm not sure if that was one of the main objectives, but it
certainly is nice).
I *was* seeing a noticeable decrease between 7.4.6 and 8.0.0RC1 running
On Mon, 2004-12-13 at 02:43, Neil Conway wrote:
On Sun, 2004-12-12 at 22:08 +, Simon Riggs wrote:
On Sun, 2004-12-12 at 05:46, Neil Conway wrote:
Is the plan to make bgwriter_percent = 100 the default setting?
Hmm...must confess that my only plan is:
i) discover dynamic behaviour
On Sun, 2004-12-12 at 05:46, Neil Conway wrote:
Simon Riggs wrote:
If the bgwriter_percent = 100, then we should actually do the sensible
thing and prepare the list that we need, i.e. limit
StrategyDirtyBufferList to finding at most bgwriter_maxpages.
Is the plan to make
On Sun, 2004-12-12 at 22:08 +, Simon Riggs wrote:
On Sun, 2004-12-12 at 05:46, Neil Conway wrote:
Is the plan to make bgwriter_percent = 100 the default setting?
Hmm...must confess that my only plan is:
i) discover dynamic behaviour of bgwriter
ii) fix any bugs or wierdness as quickly
Simon,
I am seeing a reasonably reproducible performance boost after applying
your patch (I'm not sure if that was one of the main objectives, but it
certainly is nice).
I *was* seeing a noticeable decrease between 7.4.6 and 8.0.0RC1 running
pgbench. However, after applying your patch, 8.0 is
I wonder if we even need to retain the bgwriter_percent GUC var. Is
there actually a situation in which the combination of bgwriter_maxpages
and bgwriter_delay does not give the DBA sufficient flexibility in
tuning bgwriter behavior?
Simon Riggs wrote:
If the bgwriter_percent = 100, then we
20 matches
Mail list logo
