Thread: 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