Maximum reasonable bgwriter_delay
The maximum for bgwriter_delay is currently 10 seconds. That's a long
time, and in fact if you set it to a value greater than 1 s, the sleep
is split into 1 s intervals with a call to AbsorbFsyncRequests in
between them.
Is there a use case for a setting > 1 s? We could simplify that logic a
little bit if we just set the maximum at 1 s.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
On Tue, 2007-06-19 at 15:53 +0100, Heikki Linnakangas wrote:
The maximum for bgwriter_delay is currently 10 seconds. That's a long
time, and in fact if you set it to a value greater than 1 s, the sleep
is split into 1 s intervals with a call to AbsorbFsyncRequests in
between them.Is there a use case for a setting > 1 s? We could simplify that logic a
little bit if we just set the maximum at 1 s.
Laptop mode? Linux has it...
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
Simon Riggs wrote:
On Tue, 2007-06-19 at 15:53 +0100, Heikki Linnakangas wrote:
The maximum for bgwriter_delay is currently 10 seconds. That's a long
time, and in fact if you set it to a value greater than 1 s, the sleep
is split into 1 s intervals with a call to AbsorbFsyncRequests in
between them.Is there a use case for a setting > 1 s? We could simplify that logic a
little bit if we just set the maximum at 1 s.Laptop mode? Linux has it...
Granted, though you're still going to wake up every second, so I'm not
sure how much it helps with battery life.
(/proc/sys/vm/laptop_mode won't make a difference here, AFAICS.)
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
On Tue, 19 Jun 2007, Heikki Linnakangas wrote:
Simon Riggs wrote:
Laptop mode? Linux has it...
Granted, though you're still going to wake up every second, so I'm not sure
how much it helps with battery life.
In this context, Linux's laptop mode is all about keeping the disks from
spinning up any more than they have to; the fact that the CPU does a
little something occasionally isn't so important. I don't think that's an
argument for keeping the current range for this parameter though. The
goal for a proper laptop mode tuning is for the hard drive to go minutes
at a time between waking, and whether bgwriter_delay is 1s or 10s really
isn't that big of a difference relative to that scale. Unless you dirty a
lot of memory, the laptop mode tuning is going to cache all the writes
anyway until it hits the interval where it wakes the disk to catch up.
I can't think of any good reason why the bgwriter_delay can't be reduced
to 1s if that simplifies things. You'd need a pretty old system for a
longer delay than that to be appropriate.
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
Greg Smith <gsmith@gregsmith.com> writes:
I can't think of any good reason why the bgwriter_delay can't be reduced
to 1s if that simplifies things.
The simplification Heikki suggests would save a grand total of 9 lines
of C code, two of which are braces. Is it really worth it to make such
stringent assumptions about what the parameter is good for?
(Having a GUC parameter at all costs more lines than that, not even
counting its documentation.)
regards, tom lane