Обсуждение: bgwriter and checkpoints
The bgwriter has been responsible for two main activities: incremental page cleaning and checkpointing. We've worked out the code to smooth checkpointing, but that now means we have periods where we do both page cleaning and checkpointing, and other times when we do just page cleaning. That means the processing loops are complex and that makes latch based processing more difficult to introduce. Moreover, when we perform fsyncs at the end of checkpoint we stop doing pagecleaning. I propose to introduce a new process dedicated to checkpointing, leaving the bgwriter process to perform pagecleaning, if that is requested. Note that on smaller systems the bgwriter process would not even be required to exist, if page cleaning was not used. This will simplify the code, so that checkpoint happens fairly cleanly - and can then be extended in other ways. The checkpointer would be the important process from a shutdown perspective. It will also simplify the bgwriter, potentially allowing us to consider that it performs other tasks, such as HOT vacuuming or hint bit setting. Nothing added in first version, but this clears the way to allow these things to be considered and prototyped. So the likelihood is this change will improve performance of itself in large systems, but the main benefit is code simplicity which is required for a range of potential futures. Are there objections to this work beginning? -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
2011/8/12 Simon Riggs <simon@2ndquadrant.com>: > The bgwriter has been responsible for two main activities: incremental > page cleaning and checkpointing. > > We've worked out the code to smooth checkpointing, but that now means > we have periods where we do both page cleaning and checkpointing, and > other times when we do just page cleaning. That means the processing > loops are complex and that makes latch based processing more difficult > to introduce. > > Moreover, when we perform fsyncs at the end of checkpoint we stop > doing pagecleaning. > > I propose to introduce a new process dedicated to checkpointing, > leaving the bgwriter process to perform pagecleaning, if that is > requested. Note that on smaller systems the bgwriter process would not > even be required to exist, if page cleaning was not used. > > This will simplify the code, so that checkpoint happens fairly cleanly > - and can then be extended in other ways. The checkpointer would be > the important process from a shutdown perspective. > > It will also simplify the bgwriter, potentially allowing us to > consider that it performs other tasks, such as HOT vacuuming or hint > bit setting. Nothing added in first version, but this clears the way > to allow these things to be considered and prototyped. > > So the likelihood is this change will improve performance of itself in > large systems, but the main benefit is code simplicity which is > required for a range of potential futures. > > Are there objections to this work beginning? No objections. (+100 for doing that) -- Cédric Villemain +33 (0)6 20 30 22 52 http://2ndQuadrant.fr/ PostgreSQL: Support 24x7 - Développement, Expertise et Formation
On Fri, Aug 12, 2011 at 7:09 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > The bgwriter has been responsible for two main activities: incremental > page cleaning and checkpointing. > > We've worked out the code to smooth checkpointing, but that now means > we have periods where we do both page cleaning and checkpointing, and > other times when we do just page cleaning. That means the processing > loops are complex and that makes latch based processing more difficult > to introduce. I've thought about this before, and I think it's probably a good idea.At the very least that code needs some refactoring,and breaking it into two completely separate processes may be the way to go. One possible trouble spot is that this will have the effect of increasing traffic on BgWriterCommLock. Right now, page-cleaning activity doesn't need to do that, because the bgwriter is both the source of all the fsync requests and the guy who eventually executes them, so it can just update its local state directly. If the two functions are separated, that gets a bit more complicated: the checkpoint process, even when not checkpointing, will need to absorb fsync requests every so often (maybe that could be driven off a latch, so we wake it up when the request queue is 25% full, or something like that?). Or else the cleaning process will have to be in charge of issuing the fsyncs and the checkpoint process will have to request that it do so at the appropriate time. Or maybe there's some third solution I'm not thinking of. Anyway, it may not be a big problem in practice, just something I was worrying about... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Fri, Aug 12, 2011 at 2:19 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Fri, Aug 12, 2011 at 7:09 AM, Simon Riggs <simon@2ndquadrant.com> wrote: >> The bgwriter has been responsible for two main activities: incremental >> page cleaning and checkpointing. >> >> We've worked out the code to smooth checkpointing, but that now means >> we have periods where we do both page cleaning and checkpointing, and >> other times when we do just page cleaning. That means the processing >> loops are complex and that makes latch based processing more difficult >> to introduce. > > I've thought about this before, and I think it's probably a good idea. > At the very least that code needs some refactoring, and breaking it > into two completely separate processes may be the way to go. > > One possible trouble spot is that this will have the effect of > increasing traffic on BgWriterCommLock. Right now, page-cleaning > activity doesn't need to do that, because the bgwriter is both the > source of all the fsync requests and the guy who eventually executes > them, so it can just update its local state directly. If the two > functions are separated, that gets a bit more complicated: the > checkpoint process, even when not checkpointing, will need to absorb > fsync requests every so often (maybe that could be driven off a latch, > so we wake it up when the request queue is 25% full, or something like > that?). Or else the cleaning process will have to be in charge of > issuing the fsyncs and the checkpoint process will have to request > that it do so at the appropriate time. Or maybe there's some third > solution I'm not thinking of. Anyway, it may not be a big problem in > practice, just something I was worrying about... Yes, they would still need to talk. But the good news is that they only actually need to talk once per checkpoint cycle so we can buffer them to a certain extent in shared memory to remove the worst part of such contention. Checkpointing needs a little more time in its diary to receive those messages than it has right now, so there's no easy route. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On Fri, Aug 12, 2011 at 9:33 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > Yes, they would still need to talk. But the good news is that they > only actually need to talk once per checkpoint cycle so we can buffer > them to a certain extent in shared memory to remove the worst part of > such contention. Yeah, some kind of special-purpose communication method between the cleaning scan and the checkpoint process might help, if the lock contention turns out to be a problem in practice. Then again, maybe I'm overthinking things: there's zero sign in any profiling I've done that BgWriterCommLock is even mildly contended, so even worrying about it at this point might be a waste of time. > Checkpointing needs a little more time in its diary to receive those > messages than it has right now, so there's no easy route. Yeah. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company