RE: [PoC] Non-volatile WAL buffer

Поиск
Список
Период
Сортировка
От Takashi Menjo
Тема RE: [PoC] Non-volatile WAL buffer
Дата
Msg-id 000401d5e548$7cd3a9b0$767afd10$@hco.ntt.co.jp_1
обсуждение исходный текст
Ответ на [PoC] Non-volatile WAL buffer  (Takashi Menjo <takashi.menjou.vg@hco.ntt.co.jp>)
Ответы Re: [PoC] Non-volatile WAL buffer  (Amit Langote <amitlangote09@gmail.com>)
Re: [PoC] Non-volatile WAL buffer  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: small improvement of the elapsed time for truncating heap in vacuum
Следующее
От: Craig Ringer
Дата:
Сообщение: Re: Standards compliance of SET ROLE / SET SESSION AUTHORIZATION