Re: [HACKERS] 答复:[HACKERS] about fsync in CLOG buffer write - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: [HACKERS] 答复:[HACKERS] about fsync in CLOG buffer write
Date
Msg-id CAA4eK1KGb4NNN3bhkN7xhH--tM=NewsanXXyA9ooE3op8PyNdA@mail.gmail.com
Whole thread Raw
In response to 答复:[HACKERS] about fsync in CLOG buffer write  ("周正中(德歌)" <dege.zzz@alibaba-inc.com>)
List pgsql-hackers
On Sun, Sep 6, 2015 at 7:34 AM, 周正中(德歌) <dege.zzz@alibaba-inc.com> wrote:

>On 2015-09-10 19:39:59 +0800, 张广舟(明虚) wrote:
>> We found there is a fsync call when CLOG buffer
>> is written out in SlruPhysicalWritePage(). It is often called when a backend
>> needs to check transaction status with SimpleLruReadPage().

>That's when there's not enough buffers available some other, and your
>case dirty, needs to be written out.

>You could try increasing the max (32) in CLOGShmemBuffers() further.
I think increasing  CLOGShmemBuffers have no help for our case, because PG will call pg_fsync once for every CLOG PAGE(BLOCKSZ) when ExtendCLOG。

Ideally that should not happen every time, CLOG page is written only
when there is no non-dirty CLOG buffer to accommodate a new page
during ExtendCLOG.  I think it will happen only if there is no flush of
CLOG pages by Checkpoint or by any other process trying to commit
the transaction during last 32 pages worth of transactions (which is
4 (TRANS_PER_BYTE) * 8192 (BLKSIZE) * 32 (CLOG_BUFFERS)).

What kind of workload you are using, can you once try by commenting
the sync call and see if there is any gain (I understand that is not right,
but at least we will come to know how much we can save by moving such
a sync to checkpoint).


With Regards,
Amit Kapila.

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Use pg_rewind when target timeline was switched
Next
From: Peter Moser
Date:
Subject: Re: Creating unique or "internal-use-only" column names (ColumnRef)