| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Takashi Menjo <takashi(dot)menjou(dot)vg(at)hco(dot)ntt(dot)co(dot)jp> |
| Cc: | 'Robert Haas' <robertmhaas(at)gmail(dot)com>, 'Heikki Linnakangas' <hlinnaka(at)iki(dot)fi>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: [PoC] Non-volatile WAL buffer |
| Date: | 2020-02-20 05:04:16 |
| Message-ID: | 20200220050416.etxiywcdmpgbkndw@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2020-02-17 13:12:37 +0900, Takashi Menjo wrote:
> I applied my patchset that mmap()-s WAL segments as WAL buffers to
> refs/tags/REL_12_0, and measured and analyzed its performance with
> pgbench. Roughly speaking, When I used *SSD and ext4* to store WAL,
> it was "obviously worse" than the original REL_12_0. VTune told me
> that the CPU time of memcpy() called by CopyXLogRecordToWAL() got
> larger than before.
FWIW, this might largely be because of page faults. In contrast to
before we wouldn't reuse the same pages (because they've been
munmap()/mmap()ed), so the first time they're touched, we'll incur page
faults. Did you try mmap()ing with MAP_POPULATE? It's probably also
worthwhile to try to use MAP_HUGETLB.
Still doubtful it's the right direction, but I'd rather have good
numbers to back me up :)
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2020-02-20 05:23:22 | Re: pg_regress cleans up tablespace twice. |
| Previous Message | Andres Freund | 2020-02-20 04:14:02 | Re: Improve heavyweight locks instead of building new lock managers? |