Re: Let PostgreSQL's On Schedule checkpoint write buffer smooth spread cycle by tuning IsCheckpointOnSchedule?
От | Robert Haas |
---|---|
Тема | Re: Let PostgreSQL's On Schedule checkpoint write buffer smooth spread cycle by tuning IsCheckpointOnSchedule? |
Дата | |
Msg-id | CA+TgmoZHk0PjxH40G+o=RM-Up1pq7SOqGsY+468OXfZByc1Zog@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Let PostgreSQL's On Schedule checkpoint write buffer smooth spread cycle by tuning IsCheckpointOnSchedule? (Tomas Vondra <tomas.vondra@2ndquadrant.com>) |
Ответы |
Re: Let PostgreSQL's On Schedule checkpoint write buffer
smooth spread cycle by tuning IsCheckpointOnSchedule?
|
Список | pgsql-hackers |
On Wed, Dec 23, 2015 at 2:16 PM, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote: >> Another point (which Jan Wieck made me think of) is that the optimal >> behavior here likely depends on whether xlog and data are on the same >> disk controller. If they aren't, the FPW spike and background writes >> may not interact as much. > > I'm not sure what exactly you mean by "optimal behavior" here. Surely if you > want to minimize interference between WAL and regular I/O, you'll do that. > > But I don't see what that has to do with the writes generated by the > checkpoint? If we do much more writes at the beginning of the checkpoint > (due to getting confused by FPW), and OS starts flushing that to disk > because we exceed dirty_(background)_bytes, that surely interferes with > reads (which is a major issue for queries). Well, it's true that the checkpointer dirty page writes could interfere with reads, but if you've also got lots of FPW-bloated WAL records being written to the same disk at the same time, I would think that'd be worse. No? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: