Heikki Linnakangas <[EMAIL PROTECTED]> writes: > Greg Smith wrote: > > Here are some more recent papers that also give good insight into research > > in > > this area: > > http://www.cs.usask.ca/~wew036/comprehensive.pdf > > http://www.cse.ohio-state.edu/hpcs/WWW/HTML/publications/papers/TR-05-3.pdf > > Nice papers. > > What I'd like to see is a paper on precleaning strategies. I tried to google > for one but couldn't find any. That would be very relevant to the bgwriter > tuning discussions.
I saw some listed but they were for VM managers so they may not be perfectly adaptable. > I'm still struggling to understand why and how bgwriter increases performance. > Under what circumstances, what workload? > > The only benefit I can see is that it moves the write() of a page out of the > critical path. But as long as the OS cache can absorb the write, it should be > very cheap compared to doing real I/O. Well you can't keep writing indefinitely faster than the i/o subsystem can execute the writes. Eventually the kernel will block your write until a kernel buffer becomes free. Ie, throttle your writes to the actual write bandwidth available. I think most systems are limited by the latency of reads though. Reads can't be re-ordered as well as writes can, they happen synchronously as far as an individual backend is concerned. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
