Thread: bgwriter_flush_after
I was reading about bgwriter_flush_after I found this website https://postgreshelp.com/postgresql_shared_buffers/ however, I have some questions:
First the parameter bgwriter_flush_after is amount of pages that operating system’s cache could download to disk every time Fsync is called.
Second If I want to increase the parameter bgwriter_flush_after, for instance to 2MB Will I get a better performance? and
Finally, What will be the cons of increasing this parameter?
--
Ing. Henry G. Cortez
On Thursday, October 14, 2021, Henry Francisco Garcia Cortez <garcortez@gmail.com> wrote:
I was reading about bgwriter_flush_after I found this website https://postgreshelp.com/postgresql_shared_buffers/ however, I have some questions: First the parameter bgwriter_flush_after is amount of pages that operating system’s cache could download to disk every time Fsync is called.Second If I want to increase the parameter bgwriter_flush_after, for instance to 2MB Will I get a better performance? andFinally, What will be the cons of increasing this parameter?
Pushing cache data to disk consumes I/O bandwidth. If a page is updated it eventually has to be pushed to disk. However, if it is updated again before that mandatory flush only the final version needs to be written. By attempting to spread out the I/O there is a decreased chance for that efficiency to happen. Instead, the first update gets flushed well before the mandatory time and then the second update also gets flushed. Thus the total I/O consumed is double, though this is mitigated by the fact the time period considered is spread out.
The benefits are circumstantial, which basically means figure out you have a problem first then see whether this knob can help alleviate it. Though I suppose there may be some useful guidelines to consider; I’m just not aware of them.
David J.
Ok, thanks.
El jue, 14 oct 2021 a las 15:53, David G. Johnston (<david.g.johnston@gmail.com>) escribió:
On Thursday, October 14, 2021, Henry Francisco Garcia Cortez <garcortez@gmail.com> wrote:I was reading about bgwriter_flush_after I found this website https://postgreshelp.com/postgresql_shared_buffers/ however, I have some questions:First the parameter bgwriter_flush_after is amount of pages that operating system’s cache could download to disk every time Fsync is called.Second If I want to increase the parameter bgwriter_flush_after, for instance to 2MB Will I get a better performance? andFinally, What will be the cons of increasing this parameter?Pushing cache data to disk consumes I/O bandwidth. If a page is updated it eventually has to be pushed to disk. However, if it is updated again before that mandatory flush only the final version needs to be written. By attempting to spread out the I/O there is a decreased chance for that efficiency to happen. Instead, the first update gets flushed well before the mandatory time and then the second update also gets flushed. Thus the total I/O consumed is double, though this is mitigated by the fact the time period considered is spread out.The benefits are circumstantial, which basically means figure out you have a problem first then see whether this knob can help alleviate it. Though I suppose there may be some useful guidelines to consider; I’m just not aware of them.David J.
--
Ing. Henry G. Cortez