Re: Load distributed checkpoint
От | Kevin Grittner |
---|---|
Тема | Re: Load distributed checkpoint |
Дата | |
Msg-id | 4579461A.EE98.0025.0@wicourts.gov обсуждение исходный текст |
Ответ на | Re: Load distributed checkpoint (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Load distributed checkpoint
|
Список | pgsql-hackers |
>>> On Fri, Dec 8, 2006 at 10:43 AM, in message <6439.1165596207@sss.pgh.pa.us>, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > I wonder whether it would be feasible to teach the bgwriter to get more > aggressive as the time for the next checkpoint approaches? Writes > issued early in the interval have a much higher probability of being > wasted (because the page gets re- dirtied later). But wouldn't the ones written earlier stand a much better chance of being scheduled for a physical write before the fsync? They aren't ALL re-dirtied. In our environment, we seem to be getting a lot written before the fsync with our current settings. > But maybe that just > reduces to what Takahiro- san already suggested, namely that > checkpoint- time writes should be done with the same kind of scheduling > the bgwriter uses outside checkpoints. We still have the problem that > the real I/O storm is triggered by fsync() not write(), and we don't > have a way to spread out the consequences of fsync(). We don't have a way to force writes before the fsync, but early writes to the file system encourages it. After reading this thread, I'm tempted to nudge our settings a little higher -- especially the percentages. How much overhead is there in checking whether buffer pages are dirty? -Kevin
В списке pgsql-hackers по дате отправления: