Re: Bgwriter behavior - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Bgwriter behavior
Date
Msg-id 200412272221.iBRMLVV10357@candle.pha.pa.us
Whole thread Raw
In response to Re: Bgwriter behavior  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: Bgwriter behavior
Re: Bgwriter behavior
List pgsql-hackers
Simon Riggs wrote:
> On Wed, 2004-12-22 at 04:43, Tom Lane wrote:
> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > So what are we doing for 8.0?
> > 
> > Well, it looks like RC2 has already crashed and burned --- I can't
> > imagine that Marc will let us release without an RC3 given what was
> > committed today, never mind the btree bug that Mark Wong seems to have
> > found.  So maybe we should just bite the bullet and do something real
> > about this.
> > 
> > I'm willing to code up a proposed patch for the two-track idea I
> > suggested, and if anyone else has a favorite maybe they could write
> > something too.  But do we have the resources to test such patches and
> > make a decision in the next few days?
> > 
> > At the moment my inclination is to sit on what we have.  I've not seen
> > any indication that 8.0 is really worse than earlier releases; the most
> > you could argue against it is that it's not as much better as we hoped.
> > That's not grounds to muck around at the RC3 stage.
> 
> Agreed, if somewhat reluctantly.
> 
> We may have the time to test, but it is clear that we do not have the
> time to validate those tests, then discuss and agree on the results.
> 
> Time to go with what we have.

I ran some tests last week and can report results similar on Tom's test:
pgbench -i -s 10 benchpgbench -c 10 -t 10000 bench

The tests were on a machine with a single SCSI drive that doesn't lie
about fsync.  I found 7.4.X got around 75tps while 8.0 got 100tps, very
similar to the 65/107 numbers Tom had.

First, I am confused why we have such a large improvement in 8.0.  Does
anyone know?  This is a pretty long test so a 33-50% increase is a big
jump.

Second, I added a little code in my local code to check if the
pendingOpsTable overflows and register_dirty_segment() must have a local
backend do an fsync().  I found one bgbench test had 54 local fsyncs,
but the next test had none, and 54 isn't a very larger number.

Should we emit a server log message when this happens so they can
reduce bewriter delay?

It seems having the backend do the writes is not so bad (same as 7.4.X)
and our only big problem with current bgwriter is the inability to
reduce checkpoint load for busy servers.

Should we consider at least adjusting the meaning of bgwriter_percent?

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: Jaime Casanova
Date:
Subject: Re: displaying contents
Next
From: Bruce Momjian
Date:
Subject: Ready for RC3?