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: