RE: [PoC] Non-volatile WAL buffer - Mailing list pgsql-hackers

From Takashi Menjo
Subject RE: [PoC] Non-volatile WAL buffer
Date
Msg-id 000401d5e548$7cd3a9b0$767afd10$@hco.ntt.co.jp_1
Whole thread Raw
In response to [PoC] Non-volatile WAL buffer  (Takashi Menjo <takashi.menjou.vg@hco.ntt.co.jp>)
Responses Re: [PoC] Non-volatile WAL buffer
Re: [PoC] Non-volatile WAL buffer
List pgsql-hackers
Dear hackers,

I applied my patchset that mmap()-s WAL segments as WAL buffers to refs/tags/REL_12_0, and measured and analyzed its
performancewith pgbench.  Roughly speaking, When I used *SSD and ext4* to store WAL, it was "obviously worse" than the
originalREL_12_0.  VTune told me that the CPU time of memcpy() called by CopyXLogRecordToWAL() got larger than before.
WhenI used *NVDIMM-N and ext4 with filesystem DAX* to store WAL, however, it achieved "not bad" performance compared
withour previous patchset and non-volatile WAL buffer.  Each CPU time of XLogInsert() and XLogFlush() was reduced like
asnon-volatile WAL buffer. 

So I think mmap()-ing WAL segments as WAL buffers is not such a bad idea as long as we use PMEM, at least NVDIMM-N.

Excuse me but for now I'd keep myself not talking about how much the performance was, because the mmap()-ing patchset
isWIP so there might be bugs which wrongfully  "improve" or "degrade" performance.  Also we need to know persistent
memoryprogramming and related features such as filesystem DAX, huge page faults, and WAL persistence with cache flush
andmemory barrier instructions to explain why the performance improved.  I'd talk about all the details at the
appropriatetime and place. (The conference, or here later...) 

Best regards,
Takashi

--
Takashi Menjo <takashi.menjou.vg@hco.ntt.co.jp>
NTT Software Innovation Center

> -----Original Message-----
> From: Takashi Menjo <takashi.menjou.vg@hco.ntt.co.jp>
> Sent: Monday, February 10, 2020 6:30 PM
> To: 'Robert Haas' <robertmhaas@gmail.com>; 'Heikki Linnakangas' <hlinnaka@iki.fi>
> Cc: 'pgsql-hackers@postgresql.org' <pgsql-hackers@postgresql.org>
> Subject: RE: [PoC] Non-volatile WAL buffer
>
> Dear hackers,
>
> I made another WIP patchset to mmap WAL segments as WAL buffers.  Note that this is not a non-volatile WAL
> buffer patchset but its competitor.  I am measuring and analyzing the performance of this patchset to compare
> with my N.V.WAL buffer.
>
> Please wait for a several more days for the result report...
>
> Best regards,
> Takashi
>
> --
> Takashi Menjo <takashi.menjou.vg@hco.ntt.co.jp> NTT Software Innovation Center
>
> > -----Original Message-----
> > From: Robert Haas <robertmhaas@gmail.com>
> > Sent: Wednesday, January 29, 2020 6:00 AM
> > To: Takashi Menjo <takashi.menjou.vg@hco.ntt.co.jp>
> > Cc: Heikki Linnakangas <hlinnaka@iki.fi>; pgsql-hackers@postgresql.org
> > Subject: Re: [PoC] Non-volatile WAL buffer
> >
> > On Tue, Jan 28, 2020 at 3:28 AM Takashi Menjo <takashi.menjou.vg@hco.ntt.co.jp> wrote:
> > > I think our concerns are roughly classified into two:
> > >
> > >  (1) Performance
> > >  (2) Consistency
> > >
> > > And your "different concern" is rather into (2), I think.
> >
> > Actually, I think it was mostly a performance concern (writes
> > triggering lots of reading) but there might be a consistency issue as well.
> >
> > --
> > Robert Haas
> > EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL
> > Company





pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: small improvement of the elapsed time for truncating heap in vacuum
Next
From: Craig Ringer
Date:
Subject: Re: Standards compliance of SET ROLE / SET SESSION AUTHORIZATION