NVM WAL BUFFER邮件讨论

 

本文介绍NVM WAL BUFFER的email list,详细了解开发者对此的讨论,以此深入

了解机制。

1、Heikki

使用mmap()/msync()映射WAL文件,替代WAL buffer。如果读memory-mapped文件有IO错误时,进程会通过SIGBUS杀掉。

重新阅读了[1][2],使用WAL段文件映射到内存作为WAL BUFFER,依赖于WAL文件是否放在PM上切换CPU指令或者msync()用于持久化WAL记录。

听起来挺合理,但是我没测试过。我会尝试与NVM WAL BUFFER进行比对测试。现在,有点担心对于每个段文件mmap/munmap带来的消耗。

同时提到内存映射IO的SIGBUS问题,从坏的内存块读取时会有这个问题,向这个块[3]写时也有这个问题。未来会处理这个问题。

[1] https://www.postgresql.org/message-id/83eafbfd-d9c5-6623-2423-7cab1be3888c%40iki.fi

[2] https://www.postgresql.org/message-id/2aec6e2a-6a32-0c39-e4e2-aad854543aa8%40iki.fi

[3] https://pmem.io/2018/11/26/bad-blocks.htm

https://www.postgresql.org/message-id/2aec6e2a-6a32-0c39-e4e2-aad854543aa8%40iki.fi

2、mmap/munmap带来的消耗

mmap/munmap每个WAL段文件的消耗与write一个block的消耗谁更大。mmap比read消耗大,但是减小系统调用又可以使mmap更具优势。这只是猜测,并不知道mmap真实消耗是多少。

我有一个不同想法,当重用一个段文件时,会一次写所有整个页,段文件的即使没有读取过,也会被重写。但是使用mmap时就不会有这样的行为了。只要想mapped页写一个字节,老内容就会被加载到内存。VM页在该点设置读写后,系统不知道将要写整个页。读取回收文件的老内容显然代价太过糟糕。

当修改mapped区和write()时,对于write-back行为是否有所不同。不管哪种方式,同一个文件同一个页面都会被写脏,但内核可能对何时写回磁盘有不同行为,这对性能影响很大。

这个问题可以分为两类:性能和一致性。程序的作者同样忧虑这些问题,但是也没有一个很好的答案。作者认为同一个文件被多个后端进程调用mmap(flags | MAP_SHARED)对于PM和非PM设备都是保持一致性的,但是还没找到任何如规范文件来证明。

作者在同一个mmaped文件上做了一个小程序,调用memcpy和msync,并行的地址范围不同,没发现损坏的数据。但这也无妨确保一致性,如果有损坏,作者会放弃...

作者会测试Heikki所说的使用mmap和munmap映射每个段文件,来看是否合理。

Mmap/munmap可伸缩性确实很差,但是不认为会影响我们,因为PG不是多线程。

针对mmap/munmap,这样做有很多改进。即使现在,在快速存储方面,使用open_datasync会更快(至少在O_DIRECT上)。WAL扩展是一个挑战性问题。不修改IO方式,有很多地方可以优化以提升性能:

1)将WALWriteLock分成两个锁:一个用于写,一个用于flush wal。现在,一个会话进行flush一个wal时,其他会话不能write wal,即使该wal位于其他段文件。没有必要这样做。

2)XLogFlush()中刷写WAL时不要将刷写请求的大小增加到最大(cf "try to write/flush later additions to XLOG as well" in XLogFlush()),可以显著减小OLTP负载。在SATA盘上有意义,但是对于SSD来说影响较小。写的多,持久锁时间就更长,增加了事务提交的延迟,组织更多的WAL写。

3)应该立即将所有的XLOG页的writes刷写会操作系统。现在,在OLTP负载中IO永远不会再commit之前出现,也就是说在XLogWrite()和commit之间的完全是在浪费时间。

做了这几点,猜想能有2-3倍的性能提升。但是不得不从根本上改变WAL write的IO方式。使用异步IO,可以像18k一样每秒持久化8kb的write。在我笔记本上,写4k,就是22k。

当然这和PG的wal flush没可比性,因为WAL 经常会重复写最后一个block。但不会记录到组提交里。

NVM WAL BUFFER的path:

0001-Preallocate-more-WAL-segments.patch (3K) Download Attachment
 0002-Use-WAL-segments-as-WAL-buffers.patch (40K) Download Attachment
  0003-Lazy-unmap-WAL-segments.patch (2K) Download Attachment
  0004-Speculative-map-WAL-segments.patch (1K) Download Attachment
  0005-Allocate-WAL-segments-to-utilize-hugepage.patch (1K) Download Attachment

3、是否可以模拟PM用于测试

通过“memmap=nnG!ssG”内核参数使用DRAM模拟PM。参考[1]和[2]了解详细模拟步骤。如果不起作用,检查PM和DAX的内核配置选项,比如CONFIG_FOOBAR,是否配置正确。

[1] How to Emulate Persistent Memory Using Dynamic Random-access Memory (DRAM)

https://software.intel.com/en-us/articles/how-to-emulate-persistent-memory-on-an-intel-architecture-server

[2] how_to_choose_the_correct_memmap_kernel_parameter_for_pmem_on_your_system

https://nvdimm.wiki.kernel.org/how_to_choose_the_correct_memmap_kernel_parameter_for_pmem_on_your_system

[3] Persistent Memory Wiki

https://nvdimm.wiki.kernel.org/

4、对于mmap WAL性能的测试

针对PG12分别进行修改。通过pgbench进行压测。SSD上存储WAL,map后的结果比原生PG性能差很多。VTune显示CopyXLogRecordToWAL的memcpy动作消耗的CPU时间比原生的大的多。使用NVDIMM-N,ext4-dax存储WAL,结果差不多,XLogInsert() 和XLogFlush()消耗的时间mmap和NVM WAL BUFFER的差不多。在PM上通过mmap WAL段文件作为WAL BUFFER是个很好的尝试。但是该path可能还有bug,并不能说性能提升或者下降。

5、作者的NVM WAL BUFFER测试

通过pgbench,指定不同的-c/--client和-j/--job,数据量规模因子s=50或者1000.结果如下:

Results (s=50) 

============== 
         Throughput [10^3 TPS]  Average latency [ms] 
( c, j)  before  after          before  after 
-------  ---------------------  --------------------- 
( 8, 8)  35.7    37.1 (+3.9%)   0.224   0.216 (-3.6%) 
(18,18)  70.9    74.7 (+5.3%)   0.254   0.241 (-5.1%) 
(36,18)  76.0    80.8 (+6.3%)   0.473   0.446 (-5.7%) 
(54,18)  75.5    81.8 (+8.3%)   0.715   0.660 (-7.7%) 

 

Results (s=1000) 
================ 
         Throughput [10^3 TPS]  Average latency [ms] 
( c, j)  before  after          before  after
-------  ---------------------  --------------------- 
( 8, 8)  37.4    40.1 (+7.3%)   0.214   0.199 (-7.0%) 
(18,18)  79.3    86.7 (+9.3%)   0.227   0.208 (-8.4%) 
(36,18)  87.2    95.5 (+9.5%)   0.413   0.377 (-8.7%) 
(54,18)  86.8    94.8 (+9.3%)   0.622   0.569 (-8.5%) 

 

每个规模因子下,负载和延迟都有所改进。负载在(c,j)=(36,18)下TPS最高。S=1000案例下,提升百分比较大。规模因子大,对于同表和索引的竞争就小些,也就是加锁和解锁的操作较少。这种情况下WAL对性能更重要。

条件

  1. 使用一个物理server,2个numa节点:PG绑定到node 0,pgbench到node 1,每个节点18个core,192GB的DRAM
  2. PGDATA在nvme ssd上,pg_wal在交互6-in-1的NVDIMM-N上:都安装在server端,node 0,都用ext4,NVDIMM-N被mounted时有“-o dax”
  3. 新增nvwal_path和nvwal_size参数到postgresql.conf中

步骤:

对每个(c,j)都做三次,然后取平均值:

(1) Run initdb with proper -D and -X options; and also give --nvwal-path and --nvwal-size options after patch

(2) Start postgres and create a database for pgbench tables

(3) Run "pgbench -i -s ___" to create tables (s = 50 or 1000)

(4) Stop postgres, remount filesystems, and start postgres again

(5) Execute pg_prewarm extension for all the four pgbench tables

(6) Run pgbench during 30 minutes

 

pgbench command line

====================

$ pgbench -h /tmp -p 5432 -U username -r -M prepared -T 1800 -c ___ -j ___ dbname

I gave no -b option to use the built-in "TPC-B (sort-of)" query.

软件

========

- Distro: Ubuntu 18.04

- Kernel: Linux 5.4 (vanilla kernel)

- C Compiler: gcc 7.4.0

- PMDK: 1.7

- PostgreSQL: d677550 (master on Mar 3, 2020)

 

 

硬件

========

- System: HPE ProLiant DL380 Gen10

- CPU: Intel Xeon Gold 6154 (Skylake) x 2sockets

- DRAM: DDR4 2666MHz {32GiB/ch x 6ch}/socket x 2sockets

- NVDIMM-N: DDR4 2666MHz {16GiB/ch x 6ch}/socket x 2sockets

- NVMe SSD: Intel Optane DC P4800X Series SSDPED1K750GA

 

Patch

v2-0001-Support-GUCs-for-external-WAL-buffer.patch (36K) Download Attachment
v2-0002-Non-volatile-WAL-buffer.patch (53K) Download Attachment
v2-0003-README-for-non-volatile-WAL-buffer.patch (7K) Download Attachment
nvwal-performance-s50.png (39K) Download Attachment
nvwal-performance-s1000.png (40K) Download Attachment
postgresql.conf (1K) Download Attachment

 

6、增加支持流复制

v4-0001-Support-GUCs-for-external-WAL-buffer.patch (42K) Download Attachment
v4-0002-Non-volatile-WAL-buffer.patch (73K) Download Attachment
v4-0003-walreceiver-supports-non-volatile-WAL-buffer.patch (7K) Download Attachment
v4-0004-pg_basebackup-supports-non-volatile-WAL-buffer.patch (25K) Download Attachment
v4-0005-README-for-non-volatile-WAL-buffer.patch (9K) Download Attachment

7、其他人对NVM WAL BUFFER测试

数据文件放到nvme ssd,WAL放到PM。使用下面两种方式存储WAL文件:

  1. NVM WAL BUFFER的分支,利用libpmem
  2. 通过文件系统接口访问P,就是说将PM当做传统的块设备。都是APP DIRECT方式使用PM。

进行了两种insert场景:

  1. 插入小记录,记录长度为24字节
  2. 插入大记录,记录长度328字节

初衷是看下场景2)对于WAL写密集下性能提升多大,但是发现场景1)NVM WAL BUFFER和原生PG相比有大概5%的性能提升,但是在2)有大概20%的性能衰减。

分析后,XlogFlush函数可以通过NVM WAL BUFFER提升,但是会影响CopyXlogRecordToWAL的性能。可能和PM比DRAM的memcpy延迟高有关。下面是测试结果:

Scenario A (length of record to be inserted: 24 bytes per record):

==============================

                                                                               NVWAL                           SoAD

------------------------------------              -------                          -------

Througput (10^3 TPS)                                              310.5                             296.0

CPU Time % of CopyXlogRecordToWAL                    0.4                                 0.2

CPU Time % of XLogInsertRecord                              1.5                                 0.8

CPU Time % of XLogFlush                                          2.1                                 9.6

Scenario B (length of record to be inserted: 328 bytes per record):

==============================

                                                                               NVWAL                           SoAD

------------------------------------              -------                          -------

Througput (10^3 TPS)                                              13.0                               16.9

CPU Time % of CopyXlogRecordToWAL                    3.0                                 1.6

CPU Time % of XLogInsertRecord                              23.0                               16.4

CPU Time % of XLogFlush                                          2.3                                 5.9

 

8、作者对于328字节性能衰减的回复

对于328字节,作者测试没有性能衰减,认为环境及安装步骤等可能不一样。

结果显示NVM WAL BUFFER比原始有更好性能:

 

步骤

在同一个机器上跑PG server和pgbench,分别绑定到不同的2个numa节点。Server端的numa节点用于PM和PCI SSD:

01) 创建PMEM namespace (sudo ndctl create-namespace -f -t pmem -m fsdax -M dev -e namespace0.0)

02) 在PM上做ext4文件系统并以dax方式mount(sudo mkfs.ext4 -q -F /dev/pmem0 ; sudo mount -o dax /dev/pmem0 /mnt/pmem0)

03) PCIE SSD也是ext4文件系统,正常mount(sudo mkfs.ext4 -q -F /dev/nvme0n1 ; sudo mount /dev/nvme0n1 /mnt/nvme0n1)

04) /mnt/pmem0/pg_wal 作为WAL目录

05) /mnt/nvme0n1/pgdata PGDATA目录

06) 执行initdb初始化 (initdb --locale=C --encoding=UTF8 -X /mnt/pmem0/pg_wal ...)

    - Also give -P /mnt/pmem0/pg_wal/nvwal -Q 81920 in the case of Non-volatile WAL buffer

07) 在附件的postgresql.conf中删除nvmwal_*对于原始PG测试

08) PG server绑定到NUMA node 0 (numactl -N 0 -m 0 -- pg_ctl -l pg.log start)

09) 创建database (createdb --locale=C --encoding=UTF8)

10) 使用pgbench 初始化t,s=50 (pgbench -i -s 50)

11) ALTER TABLE pgbench_history ALTER filler TYPE character(300);)

    -使表行大小为328 bytes

12) pg_ctl -l pg.log -m smart stop

13) 重新mount PMEM 和 PCIe SSD

14) numactl -N 0 -m 0 -- pg_ctl -l pg.log start

15) 执行 pg_prewarm 预热表 pgbench_* tables

16) 执行pgbench on NUMA node 1 30分钟(numactl -N 1 -m 1 -- pgbench -r -M prepared -T 1800 -c __ -j __)

- 执行默认的 tpcb-like事务

执行3次并取平均值。环境变量:

export PGHOST=/tmp

export PGPORT=5432

export PGDATABASE="$USER"

export PGUSER="$USER"

export PGDATA=/mnt/nvme0n1/pgdata

环境

- System: HPE ProLiant DL380 Gen10

- CPU: Intel Xeon Gold 6240M x2 sockets (18 cores per socket; HT disabled by BIOS)

- DRAM: DDR4 2933MHz 192GiB/socket x2 sockets (32 GiB per channel x 6 channels per socket)

- Optane PMem: Apache Pass, AppDirect Mode, DDR4 2666MHz 1.5TiB/socket x2 sockets (256 GiB per channel x 6 channels per socket; interleaving enabled)

- PCIe SSD: DC P4800X Series SSDPED1K750GA

- Distro: Ubuntu 20.04.1

- C compiler: gcc 9.3.0

- libc: glibc 2.31

- Linux kernel: 5.7 (vanilla)

- Filesystem: ext4 (DAX enabled when using Optane PMem)

- PMDK: 1.9

- PostgreSQL (Original): 14devel (200f610: Jul 26, 2020)

- PostgreSQL (Non-volatile WAL buffer): 14devel (200f610: Jul 26, 2020) + non-volatile WAL buffer patchset v4

 

 

作者按照Gang的环境配置,得到原始PG比NVM WAL BUFFER性能好的结果。需要进一步分析。NVM WAL BUFFER的XLogInsert花费的时间较长。这个拖累了XLogFlush带来的提升,整体上性能衰减了。VTune显示NVM WAL BUFFERXLogInsert => XLogInsertRecord => CopyXLogRecordsToWAL =>中memcpy花费的时间较长,XLogFlush时间较短。整体结果和Gang一致。PM上的WAL BUFFER相对于DRAM来说,memcpy WAL记录时间长,因为现阶段PM延迟比DRAM。作为回报,NVM WAL BUFFER减小了让记录命中设备的时间,因为不需要将他们从缓冲区写到其他地方,只需要将CPU cache中内容持久化到NVM。会继续跟踪。

原文

https://www.postgresql-archive.org/PoC-Non-volatile-WAL-buffer-td6120484.html

已标记关键词 清除标记
©️2020 CSDN 皮肤主题: 博客之星2020 设计师:CY__ 返回首页
实付 9.90元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值