Re: Disabling bgwriter on my notebook

From: "Michael Paesold" <mpaesold(at)gmx(dot)at>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-hackers(at)postgresql(dot)org>, "Jan Wieck" <JanWieck(at)Yahoo(dot)com>
Subject: Re: Disabling bgwriter on my notebook
Date: 2004-09-17 21:25:23
Message-ID: 012e01c49cfc$d7cfd4b0$d604460a@zaphod
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> You can't turn off the bgwriter process entirely anymore, because we
> rely on it for checkpoints. However I suppose there's no solid reason
> not to allow bgwriter_delay to be set as high as checkpoint_timeout,
> which would accomplish your goal of not spinning up the laptop disk very
> often.

Sounds reasonable. Please change it that way.

> This reminds me of another issue I'd been meaning to bring up, which is
> whether the default bgwriter settings are reasonable:
>
> > #bgwriter_delay = 200 # 10-5000 milliseconds
> > #bgwriter_percent = 1 # 1-100% of dirty buffers
> > #bgwriter_maxpages = 100 # 1-1000 buffers max at once

> ISTM that writing only 1% of dirty buffers per cycle isn't going to go
> very far in terms of keeping the freelist clean. I was wondering if the
> default on that shouldn't be higher. If 1% *is* a reasonable setting,
> then don't we need finer granularity --- maybe the setting should be in
> tenths of a percent? Having the default right up against the end of the
> possible range doesn't sound right.

#checkpoint_timeout = 300 # range 30-3600, in seconds

First I thought this setting could be put in relation to the checkpoint
timeout directly, but it can't. It really depends on the "creation rate" of
dirty buffers.

Different approach: what bgwriter should do (if I am correct) is flush
enough dirty buffers between checkpoints so that there are only the least
recently touched ones left for syncing to disk.
(Anyway, how does the bgwriter select which dirty buffers to sync?)

So for testing it would be nice to know:
* how many dirty buffers are left for syncing during checkpoint?
* how many dirty buffers are synced between checkpoints
* how many unique disk pages are those; or how many disk pages have been
flushed more than once during that time

Is there currently debug output in the code that could tell me answers to
those questions? If so, I could try to some testing.

> Jan, you're probably the only one who's done any serious testing of
> alternatives for this --- what do you think?

Best Regards,
Michael Paesold

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Wheeler 2004-09-17 21:28:36 Re: libpq and prepared statements progress for 8.0
Previous Message Tom Lane 2004-09-17 21:21:59 Re: libpq and prepared statements progress for 8.0