Re: checkpointer continuous flushing - V18

On 2016-03-10 23:43:46 +0100, Fabien COELHO wrote:
> 
> >       <para>
> >        Whenever more than <varname>bgwriter_flush_after</varname> bytes have
> >        been written by the bgwriter, attempt to force the OS to issue these
> >        writes to the underlying storage.  Doing so will limit the amount of
> >        dirty data in the kernel's page cache, reducing the likelihood of
> >        stalls when an fsync is issued at the end of a checkpoint, or when
> >        the OS writes data back  in larger batches in the background.  Often
> >        that will result in greatly reduced transaction latency, but there
> >        also are some cases, especially with workloads that are bigger than
> >        <xref linkend="guc-shared-buffers">, but smaller than the OS's page
> >        cache, where performance might degrade.  This setting may have no
> >        effect on some platforms.  <literal>0</literal> disables controlled
> >        writeback. The default is <literal>256Kb</> on Linux, <literal>0</>
> >        otherwise. This parameter can only be set in the
> >        <filename>postgresql.conf</> file or on the server command line.
> >       </para>
> >
> >(plus adjustments for the other gucs)

> What about the maximum value?

Added.
     <varlistentry id="guc-bgwriter-flush-after" xreflabel="bgwriter_flush_after">
<term><varname>bgwriter_flush_after</varname>(<type>int</type>)      <indexterm>
<primary><varname>bgwriter_flush_after</>configuration parameter</primary>      </indexterm>      </term>
<listitem>      <para>        Whenever more than <varname>bgwriter_flush_after</varname> bytes have        been written
bythe bgwriter, attempt to force the OS to issue these        writes to the underlying storage.  Doing so will limit
theamount of        dirty data in the kernel's page cache, reducing the likelihood of        stalls when an fsync is
issuedat the end of a checkpoint, or when        the OS writes data back in larger batches in the background.  Often
   that will result in greatly reduced transaction latency, but there        also are some cases, especially with
workloadsthat are bigger than        <xref linkend="guc-shared-buffers">, but smaller than the OS's page        cache,
whereperformance might degrade.  This setting may have no        effect on some platforms.  The valid range is between
     <literal>0</literal>, which disables controlled writeback, and        <literal>2MB</literal>.  The default is
<literal>256Kb</>on Linux,        <literal>0</> elsewhere.  (Non-default values of        <symbol>BLCKSZ</symbol>
changethe default and maximum.)        This parameter can only be set in the <filename>postgresql.conf</>        file
oron the server command line.       </para>      </listitem>     </varlistentry>    </variablelist>
 


> If the default is in pages, maybe you could state it and afterwards
> translate it in size.

Hm, I think that's more complicated for users than it's worth.


> The text could say something about sequential writes performance because
> pages are sorted.., but that it is lost for large bases and/or short
> checkpoints ?

I think that's an implementation detail.


- Andres