Thank you for your reply. <CA+TgmobUrKBWgOa8x=mbW4Cmsb=nev8egf+rslp7xicajhd...@mail.gmail.com> Wed, 17 Jan 2018 15:29:11 -0500Robert Haas <robertmh...@gmail.com> wrote : >> Using pgbench which is a PostgreSQL general benchmark, the postgres server >> to which the patches is applied is about 5% faster than original server. >> And using my insert benchmark, it is up to 90% faster than original one. >> I will describe these details later. > >Interesting. But your insert benchmark looks highly artificial... in >real life, you would not insert the same long static string 160 >million times. Or if you did, you would use COPY or INSERT .. SELECT.
I made this benchmark in order to put very heavy WAL I/O load on PMEM. PMEM is very fast. I ran the micro-benchmark test like fio on PMEM. This workload involved 8K Bytes-block synchronous sequential writes, and the total write size was 40G Bytes. The micro-benchmark result was the following. Using DAX FS(like fdatasync): 5,559 MB/sec Using DAX FS and PMDK(like pmem_drain): 13,177 MB/sec Using pgbench, the postgres server to which my patches were applied was only 5% faster than the original server. >> The averages of running pgbench three times are: >> wal_sync_method=fdatasync: tps = 43,179 >> wal_sync_method=pmem_drain: tps = 45,254 While this pgbench was running, the utilization of 8 CPU cores(on which the postgres server was runnnig) was about 800%, and the throughput of WAL I/O was about 10 MB/sec. I thought that pgbench was not enough to put heavy WAL I/O load on PMEM. So I made and ran the WAL I/O intensive test. Do you know any good WAL I/O intensive benchmarks? DBT2? <ca+tgmoawgn6z8pclkrmrgg99hf0028sfs2a1_vqemdkcjjq...@mail.gmail.com> Wed, 17 Jan 2018 15:40:25 -0500Robert Haas <robertmh...@gmail.com> wrote : >> C-5. Running the 2 benchmarks(1. pgbench, 2. my insert benchmark) >> C-5-1. pgbench >> # numactl -N 1 pgbench -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? This scale factor was 200. # numactl -N 0 pgbench -s 200 -i [DB_NAME] >Was the only non-default configuration setting wal_sync_method? i.e. >synchronous_commit=on? No change to max_wal_size? No, I used the following parameter in postgresql.conf to prevent checkpoints from occurring while running the tests. # - Settings - wal_level = replica fsync = on synchronous_commit = on wal_sync_method = pmem_drain full_page_writes = on wal_compression = off # - Checkpoints - checkpoint_timeout = 1d max_wal_size = 20GB min_wal_size = 20GB >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. > Thank you for your kind proposal. I did that. # numactl -N 0 pgbench -s 200 -i [DB_NAME] # numactl -N 1 pgbench -c 32 -j 32 -T 1800 -M prepared [DB_NAME] The averages of running pgbench three times are: wal_sync_method=fdatasync: tps = 39,966 wal_sync_method=pmem_drain: tps = 41,365 -- Yoshimi Ichiyanagi
