Jan Wieck wrote: > > If the background cleaner has to not just write() but write/fsync or > > write/O_SYNC, it isn't going to be able to clean them fast enough. It > > creates a bottleneck where we didn't have one before. > > > > We are trying to eliminate an I/O storm during checkpoint, but the > > solutions seem to be making the non-checkpoint times slower. > > > > It looks as if you're assuming that I am making the backends unable to > write on their own, so that they have to wait on the checkpointer. I > never said that. > > If the checkpointer keeps the LRU heads clean, that lifts off write load > from the backends. Sure, they will be able to dirty pages faster. > Theoretically, because in practice if you have a reasonably good cache > hitrate, they will just find already dirty buffers where they just add > some more dust. > > If after all the checkpointer (doing write()+whateversync) is not able > to keep up with the speed of buffers getting dirtied, the backends will > have to do some write()'s again, because they will eat up the clean > buffers at the LRU head and pass the checkpointer.
Yes, there are a couple of issues here --- first, have a background writer to write dirty pages. This is good, no question. The bigger question is removing sync() and using fsync() or O_SYNC for every write --- if we do that, the backends doing private write will have to fsync their writes too, meaning if the checkpointer can't keep up, we now have backends doing slow writes too. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
