On Wed, 12 Aug 2009, sam mulube wrote:
> is my interpreting of buffers_clean = 0 correct?
Yes.
> If so, why would the bgwriter not be writing out any buffers?
The purpose of the cleaner is to prepare buffers that we expect will be
needed for allocations in the near future. Let's do a little math on your
system to guess why that's not happening.
> checkpoints_timed = 333
> checkpoints_req = 0
You're never triggering checkpoints from activity. This suggests that
your system is having a regular checkpoint every 5 minutes, and therefore
the time your server has been up is about 1665 minutes.
> bgwriter_delay = 200ms
With the background writer running 5 times per second, the data you've
sampled involved it running 1665 * 60 * 5 = 499500 times. During none of
those runs did it actually write anything; why?
> buffers_alloc = 19163
During those runs, 19163 buffers were allocated. This means that during
the average background writer delay nap, 19163 / 499500 = 0.04 buffers
were allocated. That's very little demand for buffers that need to be
cleaned on average, and the evidence here suggests the system is finding
plenty of cleaned up and ready to go buffers from the background
checkpoint process. It doesn't need to do any work on top of what the
checkpoint buffer cleanup is doing.
> buffers_backend = 740
This number represents the behavior the background writer is trying to
prevent--backends having to clean their own buffers up. Your result here
suggests that on average, during any 5 minute period there are 740 / 333 =
2.2 buffers being written that we might have had the background writer
take care of instead. Again, that's so little activity that the averages
the background writer estimates with aren't even detecting anything worth
doing.
In short, your system isn't nearly active enough for the background writer
to find itself with useful work to do, and one of the design goals for it
was to keep it from spinning around doing nothing in that situation. If
your system load goes up, I expect you'll discover cleaning starts
happening too.
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
