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 gsm...@gregsmith.com http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
