Re: Bgwriter behavior

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bgwriter behavior
Date: 2004-12-22 04:25:12
Message-ID: 200412220425.iBM4PCh14361@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > First, we remove the GUC bgwriter_maxpages because I don't see a good
> > way to set a default for that. A default value needs to be based on a
> > percentage of the full buffer cache size.
>
> This is nonsense. The admin knows what he set shared_buffers to, and so
> maxpages and percent of shared buffers are not really distinct ways of
> specifying things. The cases that make a percent spec useful are if
> (a) it is a percent of a non-constant number (eg, percent of total dirty
> pages as in the current code), or (b) it is defined in a way that lets
> it limit the amount of scanning work done (which it isn't useful for in
> the current code). But a maxpages spec is useful for (b) too. More to
> the point, maxpages is useful to set a hard limit on the amount of I/O
> generated by the bgwriter, and I think people will want to be able to do
> that.

I figured that if we specify a percentage users would not need to update
this value regularly if they increase their shared buffers. I agree if
you want to limit total I/O by the bgwriter an actual pages a count is
better but I assumed we were looking for bgwriter to do a certain
percentage of total writes. If the system is doing a lot of writes then
limiting the bgwriter doesn't help because then the backends are going
to have to do the writes themselves.

> > Now, to control the bgwriter frequency we multiply the percent of the
> > list it had to span by the bgwriter_delay value to determine when to run
> > bgwriter next.
>
> I'm less than enthused about this. The idea of the bgwriter is to
> trickle out writes in a way that doesn't affect overall performance too
> much. Not to write everything in sight at any cost.

No question my idea makes tuning diffcult. I was hoping it would be
self-tuning but I am not sure.

> I like the hybrid "keep the bottom of the ARC list clean, plus do a slow
> clock scan on the main buffer array" approach better. I can see that
> that directly impacts both of the goals that the bgwriter has. I don't
> see how a variable I/O rate really improves life on either score; it
> just makes things harder to predict.

So what are we doing for 8.0?

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-12-22 04:43:21 Re: Bgwriter behavior
Previous Message Rod Taylor 2004-12-22 00:53:00 Slow tab completion (7.4)

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2004-12-22 04:43:21 Re: Bgwriter behavior
Previous Message Euler Taveira de Oliveira 2004-12-22 03:57:34 Re: uptime function to postmaster