Re: Separating bgwriter and checkpointer

On Tue, Sep 20, 2011 at 15:35, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> On 20.09.2011 16:29, Greg Stark wrote:
>>
>> On Tue, Sep 20, 2011 at 11:03 AM, Simon Riggs<simon(at)2ndquadrant(dot)com>
>>  wrote:
>>>>
>>>> I don't see what difference it makes which process does the I/O. If a
>>>> write() by checkpointer process blocks, any write()s by the separate
>>>> bgwriter process at that time will block too. If the I/O is not
>>>> saturated,
>>>> and the checkpoint write()s don't block, then even without this patch,
>>>> the
>>>> bgwriter process can handle its usual bgwriter duties during checkpoint
>>>> just
>>>> fine. (And if the I/O is not saturated, it's not an I/O bound system
>>>> anyway.)
>>>
>>> Whatever value you assign to the bgwriter, then this patch makes sure
>>> that happens during heavy fsyncs.
>>
>> I think his point is that it doesn't because if the heavy fsyncs cause
>> the system to be i/o bound it then bgwriter will just block issuing
>> the writes instead of the fsyncs.
>>
>> I'm not actually convinced. Writes will only block if the kernel
>> decides to block. We don't really know how the kernel makes this
>> decision but it's entirely possible that having pending physical i/o
>> issued due to an fsync doesn't influence the decision if there is
>> still a reasonable number of dirty pages in the buffer cache.  In a
>> sense, "I/O bound" means different things for write and fsync. Or to
>> put it another way fsync is latency sensitive but write is only
>> bandwidth sensitive.
>
> Yeah, I was thinking of write()s, not fsyncs. I agree this might have some
> effect during fsync phase.
>
>> All that said my question is which way is the code more legible and
>> easier to follow?
>
> Hear hear. If we're going to give the bgwriter more responsibilities, this
> might make sense even if it has no effect on performance.

Isn't there also the advantage of that work put in two different
processes can use two different CPU cores? Or is that likely to never
ever come in play here?

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/