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
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 |