Re: [HACKERS][PATCH] Applying PMDK to WAL operations for persistent memory

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Yoshimi Ichiyanagi <ichiyanagi(dot)yoshimi(at)lab(dot)ntt(dot)co(dot)jp>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, menjo(dot)takashi(at)lab(dot)ntt(dot)co(dot)jp, ishizaki(dot)teruaki(at)lab(dot)ntt(dot)co(dot)jp
Subject: Re: [HACKERS][PATCH] Applying PMDK to WAL operations for persistent memory
Date: 2018-01-17 20:40:25
Message-ID: CA+TgmoawGN6Z8PcLKrMrGg99hF0028sFS2a1_VQEMDKcJjQDMQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jan 16, 2018 at 2:00 AM, Yoshimi Ichiyanagi
<ichiyanagi(dot)yoshimi(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> C-5. Running the 2 benchmarks(1. pgbench, 2. my insert benchmark)
> C-5-1. pgbench
> # numactl -N 1 pgbech -c 32 -j 8 -T 120 -M prepared [DB_NAME]
>
> The averages of running pgbench three times are:
> wal_sync_method=fdatasync: tps = 43,179
> wal_sync_method=pmem_drain: tps = 45,254

What scale factor was used for this test?

Was the only non-default configuration setting wal_sync_method? i.e.
synchronous_commit=on? No change to max_wal_size?

This seems like an exceedingly short test -- normally, for write
tests, I recommend the median of 3 30-minute runs. It also seems
likely to be client-bound, because of the fact that jobs = clients/4.
Normally I use jobs = clients or at least jobs = clients/2.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2018-01-17 20:41:13 Re: PostgreSQL crashes with SIGSEGV
Previous Message Tom Lane 2018-01-17 20:37:34 Re: [HACKERS] postgres_fdw bug in 9.6