使用ScaleFlux公司的csd2000卡大幅提升PostgreSQL性能 原作者:唐成 创作时间:2020-02-05 16:47:53+08 |
wangliyun 发布于2020-02-06 08:00:00
![]() ![]() ![]() ![]() ![]() |
作者介绍
唐成: 网名 osdba,《PostgreSQL修炼之道:从小工到专家》的作者,中启乘数科技公司联合创始人,从业20年,从事PostgreSQL数据库超过10年,拥有十几年数据库、操作系统、存储领域的工作经验,历任过网易研究院技术专家、阿里巴巴高级数据库专家,从事过阿里巴巴PostgreSQL、Greenplum数据库的架构设计和运维。做过数个百TB以上的Greenplum集群的维护和扩容工作,解决过很多PostgreSQL、Greenplum方面的疑难杂症。
1. 文章介绍
本文详细讲解了把fillfactor参数调整到70%时,使用csd2000的透明压缩功能让实际占用空间很少增长的情况下(增长8%),让pgbench测试出来的性能提升近40%。同时使用了csd2000的透明压缩功能让空间占用率到达了原空间的六分之一,大大的节省了空间。
2. 测试场景
原先我就使用过scaleflux公司的css1000的卡,css1000的卡就有旁路压缩的功能,使用这种压缩的功能通常需要修改代码,把代码中原先调用的gzip压缩库改到scaleflux公司提供的压缩库上面,这时就可以让压缩走到硬件上,大大地节省了CPU,但这种方式需要修改代码,通用性不强。
最近听说scaleflux公司的新品csd2000有透明压缩的功能,感觉这个功能正是我们开源数据库期待的功能,迫不及待找他们申请了一块csd2000的卡做测试。
把这个卡安装在我的R730xd的测试机上,同时按官方的指导安装好驱动程序(我的操作系统是CentOS7.6),然后就可以看到这个盘出来了:
[root@cssrv21 ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sdb 8:16 0 558.4G 0 disk
├─sdb2 8:18 0 20G 0 part /
├─sdb3 8:19 0 16G 0 part [SWAP]
└─sdb1 8:17 0 50G 0 part
sfdv0n1 250:0 0 8.7T 0 disk /data
其中/dev/sfdv0n1就是csd2000的盘。 为了看出透明压缩的效果,把原先借的css1000的卡安装在另一台的Dell R730xd的机器上,然后做对比测试。 目前借到的csd2000盘的实际容量是3.2TB,做成了3倍的容量,大约9.6T,把这个盘上格式化出文件系统,准备开测:
mkfs -t ext4 /dev/sfdv0n1
mount -o discard /dev/sfdv0n1 /data
chown postgres.postgres /data
su - postgres
mkdir /data/pgdata
PostgreSQL数据库使用的是11.6,用initdb初始化数据库,其中postgresql.conf中主要配置这几个参数:
listen_addresses = '*'
max_connections = 1000
unix_socket_directories = '/tmp'
shared_buffers = 128MB
max_wal_size = 10GB
min_wal_size = 8GB
vacuum_cost_limit = 10000\
vacuum_cost_delay = 1
其它参数保留默认值。 把数据库的数据目录建到/data/pgdata下,运行pgbench做测试,用pgbench造10亿条记录,估计数据量在150多GB。
3. 实际的测试
3.1 普通的测试
3.1.1 测试csd2000卡
[postgres@cssrv21 ~]$ time pgbench -i -s 10000
dropping old tables...
NOTICE: table "pgbench_accounts" does not exist, skipping
NOTICE: table "pgbench_branches" does not exist, skipping
NOTICE: table "pgbench_history" does not exist, skipping
NOTICE: table "pgbench_tellers" does not exist, skipping
creating tables...
generating data...
100000 of 1000000000 tuples (0%) done (elapsed 0.09 s, remaining 878.83 s)
200000 of 1000000000 tuples (0%) done (elapsed 0.18 s, remaining 884.39 s)
300000 of 1000000000 tuples (0%) done (elapsed 0.27 s, remaining 908.15 s)
400000 of 1000000000 tuples (0%) done (elapsed 0.38 s, remaining 959.26 s)
...
...
999700000 of 1000000000 tuples (99%) done (elapsed 927.94 s, remaining 0.28 s)
999800000 of 1000000000 tuples (99%) done (elapsed 928.02 s, remaining 0.19 s)
999900000 of 1000000000 tuples (99%) done (elapsed 928.12 s, remaining 0.09 s)
1000000000 of 1000000000 tuples (100%) done (elapsed 928.19 s, remaining 0.00 s)
vacuuming...
creating primary keys...
done.
real 30m13.212s
user 3m49.150s
sys 0m5.648s
造数据花了30分钟。
数据库层占用的空间情况:
[root@cssrv21 data]# du -sh pgdata
158G pgdata
scaleflux提供了csd-size.sh的工具查看实际占用的空间情况:
[root@cssrv21 ~]# ./csd-size.sh
Usage:
csd-size.sh csd_dev_name
Example:
csd-size.sh sfdv0n1
No device name given, default to use name "sfdv0n1".
Device - /dev/sfdv0n1
Total capacity - 2977 GiB
Used space - 25 GiB
Free space - 2952 GiB
Logical data size - 227 GiB
Compression ratio - 8.94 (logical data size / used space)
可以看到实际只占用了25GB,也就是说158GB的数据压缩到倍25GB,压缩率达到了6.3倍,还是很可观的。
在csd2000卡上做压力测试:
[postgres@cssrv21 ~]$ pgbench -j 128 -c 128 -T 300
starting vacuum...end.
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 10000
query mode: simple
number of clients: 128
number of threads: 128
duration: 300 s
number of transactions actually processed: 9059584
latency average = 4.239 ms
tps = 30196.497967 (including connections establishing)
tps = 30198.786610 (excluding connections establishing)
3.1.2 css1000卡
同样在另一机器上测试css1000的卡:
[postgres@cssrv22 pgdata]$ time pgbench -i -s 10000
dropping old tables...
NOTICE: table "pgbench_accounts" does not exist, skipping
NOTICE: table "pgbench_branches" does not exist, skipping
NOTICE: table "pgbench_history" does not exist, skipping
creating tables...
generating data...
100000 of 1000000000 tuples (0%) done (elapsed 0.07 s, remaining 658.03 s)
200000 of 1000000000 tuples (0%) done (elapsed 0.16 s, remaining 796.76 s)
...
...
999700000 of 1000000000 tuples (99%) done (elapsed 917.29 s, remaining 0.28 s)
999800000 of 1000000000 tuples (99%) done (elapsed 917.38 s, remaining 0.18 s)
999900000 of 1000000000 tuples (99%) done (elapsed 917.48 s, remaining 0.09 s)
1000000000 of 1000000000 tuples (100%) done (elapsed 917.57 s, remaining 0.00 s)
vacuuming...
creating primary keys...
done.
real 24m39.065s
user 3m45.821s
sys 0m5.443s
在css1000的卡上造数据花了24分钟,看起来比css2000要快。
同样在css1000卡上做压力测试:
[postgres@cssrv22 data]$ time pgbench -j 128 -c 128 -T 300
starting vacuum...end.
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 10000
query mode: simple
number of clients: 128
number of threads: 128
duration: 300 s
number of transactions actually processed: 8590121
latency average = 4.471 ms
tps = 28629.717270 (including connections establishing)
tps = 28631.618435 (excluding connections establishing)
real 5m0.382s
user 8m59.223s
sys 11m13.547s
发现csd2000的卡的pgbench的性能(3万)比css1000卡的性能(约2.9万)高一些。
3.2 调整fillfactor的测试
从空间收益来看,如果数据可以压缩,可以节省几倍的空间,还是有很大的收益,但性能提升不多。scaleflux的工程师告诉我,通过调整PostgreSQL表的fillfactor参数,可以让空间占用率基本不增加的情况下,可以大大提升性能。从理论上讲,默认情况下fillfactor是100%,但我们可以调整成70%,这时PostgreSQL的写性能会得到提高。如果没有使用csd2000的卡,当把fillfactor参数调小,会相应带来空间的增加,但因为使用csd2000的透明压缩功能后,即使把当把fillfactor参数调小,压缩后的实际占用空间应该不会提高太多。
理论归理论,还是看我们的实测,看看实际的效果如何:
[postgres@cssrv21 ~]$ time pgbench -i -s 10000 -F 70
dropping old tables...
999900000 of 1000000000 tuples (99%) done (elapsed 1027.00 s, remaining 0.10 s)
1000000000 of 1000000000 tuples (100%) done (elapsed 1027.10 s, remaining 0.00 s)
vacuuming...
creating primary keys...
done.
real 35m10.789s
user 3m51.888s
sys 0m5.489s
造数据的时间是35分钟,原先是30分钟,稍变长了一些。 查看空间占用:
[root@cssrv21 ~]# ./csd-size.sh
Usage:
csd-size.sh csd_dev_name
Example:
csd-size.sh sfdv0n1
No device name given, default to use name "sfdv0n1".
Device - /dev/sfdv0n1
Total capacity -2977 GiB
Used space -27 GiB
Free space -2950 GiB
Logical data size - 277 GiB
Compression ratio - 10.08 (logical data size / used space)
空间是27GB,比原先25GB只涨了2GB,远远没有涨到30%那么多,确实验证了前面的理论。 再看pgbench测试出来的性能:
[postgres@cssrv21 ~]$ pgbench -j 128 -c 128 -T 60
starting vacuum...end.
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 10000
query mode: simple
number of clients: 128
number of threads: 128
duration: 60 s
number of transactions actually processed: 2508991
latency average = 3.063 ms
tps = 41787.598119 (including connections establishing)
tps = 41803.617591 (excluding connections establishing)
发现tps从3万猛涨到4.2万,涨了近40%的性能。
再做一个更猛的,把fillfactor降低到50%:
[postgres@cssrv21 ~]$ time pgbench -i -s 10000 -F 50
dropping old tables...
creating tables...
generating data...
100000 of 1000000000 tuples (0%) done (elapsed 2.71 s, remaining 27112.63 s)
200000 of 1000000000 tuples (0%) done (elapsed 2.84 s, remaining 14181.00 s)
...
...
999700000 of 1000000000 tuples (99%) done (elapsed 1168.05 s, remaining 0.35 s)
999800000 of 1000000000 tuples (99%) done (elapsed 1168.16 s, remaining 0.23 s)
999900000 of 1000000000 tuples (99%) done (elapsed 1168.27 s, remaining 0.12 s)
1000000000 of 1000000000 tuples (100%) done (elapsed 1168.39 s, remaining 0.00 s)
vacuuming...
creating primary keys...
done.
real 42m19.784s
user 3m53.464s
sys 0m5.717s
查看压缩后的空间占用:
[root@cssrv21 ~]# ./csd-size.sh
Usage:
csd-size.sh csd_dev_name
Example:
csd-size.sh sfdv0n1
No device name given, default to use name "sfdv0n1".
Device - /dev/sfdv0n1
Total capacity - 2977 GiB
Used space - 30 GiB
Free space - 2947 GiB
Logical data size - 355 GiB
Compression ratio - 11.80 (logical data size / used space)
实际占用的空间上升到了30GB。 查看文件系统上的空间大小:
[root@cssrv21 data]# du -sh pgdata
286G pgdata
空间大小是286GB。
看pgbench的测试结果:
[postgres@cssrv21 ~]$ pgbench -j 128 -c 128 -T 300
starting vacuum...end.
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 10000
query mode: simple
number of clients: 128
number of threads: 128
duration: 300 s
number of transactions actually processed: 13208072
latency average = 2.908 ms
tps = 44012.763817 (including connections establishing)
tps = 44016.173486 (excluding connections establishing)
可以看到tps为4.4万,与原先fillfactor=70%时,上涨了一些,但上涨不多,所以看起来还是应该把fillfactor设置成70%比较合适,如果变成50%,收益就没有这个大了。
4. 测试结论
在PostgreSQL数据库中,使用csd2000的卡,既能省空间(在pgbench造的数据可以节省6倍的空间),还能提升性能,对于pgbench的测试场景(为TPC-B的测试场景)可以提升30~40%的性能。
5. 关于使用空间的监控
有人问实际空间3.2T,做成了9.6T的卡,是否会出现当压缩率没有3倍这么高时,实际的空间没有了,但显示还有很多空闲空间还可以使用的情况,从而导致严重的问题?这个问题是不会出现的,ScaleFlux公司已经想到了这个问题,装完他们卡的整个驱动程序后内部有一个容量管理的程序,这个程序会让“df -h”看到的空间占用率是准确的,当实际的空间占用率到达80%时,通过“df -h”看到的空间占用率也是正确的80%,这样监控程序就可以准确告警出来,不会导致空间满而没有发现的问题。不过这里需要注意,不能把csd2000的盘用LVM管理,否则就无法正确使用容量管理程序的这个功能了。另在mount盘时一定要加上“discard”选项,如类似下面这样:
mount -o discard /dev/sfdv0n1 /data
否则没有了trim的功能,删除一个大文件,实际占用的空间不会释放,这会导致严重的问题。
请在登录后发表评论,否则无法保存。