唐成: 网名 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），然后就可以看到这个盘出来了：NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT├─sdb3 8:19 0 16G 0 part [SWAP]sfdv0n1 250:0 0 8.7T 0 disk data其中/dev/sfdv0n1就是csd2000的盘。为了看出透明压缩的效果，把原先借的css1000的卡安装在另一台的Dell R730xd的机器上，然后做对比测试。目前借到的csd2000盘的实际容量是3.2TB，做成了3倍的容量，大约9.6T，把这个盘上格式化出文件系统，准备开测：mount -o discard dev/sfdv0n1 datachown postgres.postgres /dataPostgreSQL数据库使用的是11.6，用initdb初始化数据库，其中postgresql.conf中主要配置这几个参数：unix_socket_directories = '/tmp'vacuum_cost_limit = 10000\把数据库的数据目录建到/data/pgdata下，运行pgbench做测试，用pgbench造10亿条记录，估计数据量在150多GB。3. 实际的测试
3.1 普通的测试
3.1.1 测试csd2000卡
[postgres@cssrv21 ~]$ time pgbench -i -s 10000NOTICE: table "pgbench_accounts" does not exist, skippingNOTICE: table "pgbench_branches" does not exist, skippingNOTICE: table "pgbench_history" does not exist, skippingNOTICE: table "pgbench_tellers" does not exist, skipping100000 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)[root@cssrv21 data]# du -sh pgdatascaleflux提供了csd-size.sh的工具查看实际占用的空间情况：[root@cssrv21 ~]# ./csd-size.shNo device name given, default to use name "sfdv0n1".Total capacity - 2977 GiBLogical data size - 227 GiBCompression ratio - 8.94 (logical data size / used space)可以看到实际只占用了25GB，也就是说158GB的数据压缩到倍25GB，压缩率达到了6.3倍，还是很可观的。[postgres@cssrv21 ~]$ pgbench -j 128 -c 128 -T 300transaction type: <builtin: TPC-B (sort of)>number of transactions actually processed: 9059584latency average = 4.239 mstps = 30196.497967 (including connections establishing)tps = 30198.786610 (excluding connections establishing)3.1.2 css1000卡
[postgres@cssrv22 pgdata]$ time pgbench -i -s 10000NOTICE: table "pgbench_accounts" does not exist, skippingNOTICE: table "pgbench_branches" does not exist, skippingNOTICE: table "pgbench_history" does not exist, skipping100000 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)在css1000的卡上造数据花了24分钟，看起来比css2000要快。[postgres@cssrv22 data]$ time pgbench -j 128 -c 128 -T 300transaction type: <builtin: TPC-B (sort of)>number of transactions actually processed: 8590121latency average = 4.471 mstps = 28629.717270 (including connections establishing)tps = 28631.618435 (excluding connections establishing)发现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 70999900000 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)造数据的时间是35分钟，原先是30分钟，稍变长了一些。[root@cssrv21 ~]# ./csd-size.shNo device name given, default to use name "sfdv0n1".Logical data size - 277 GiBCompression ratio - 10.08 (logical data size / used space)空间是27GB，比原先25GB只涨了2GB，远远没有涨到30%那么多，确实验证了前面的理论。[postgres@cssrv21 ~]$ pgbench -j 128 -c 128 -T 60transaction type: <builtin: TPC-B (sort of)>number of transactions actually processed: 2508991latency average = 3.063 mstps = 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 50100000 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)[root@cssrv21 ~]# ./csd-size.shNo device name given, default to use name "sfdv0n1".Total capacity - 2977 GiBLogical data size - 355 GiBCompression ratio - 11.80 (logical data size / used space)实际占用的空间上升到了30GB。查看文件系统上的空间大小：[root@cssrv21 data]# du -sh pgdata[postgres@cssrv21 ~]$ pgbench -j 128 -c 128 -T 300transaction type: <builtin: TPC-B (sort of)>number of transactions actually processed: 13208072latency average = 2.908 mstps = 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的功能，删除一个大文件，实际占用的空间不会释放，这会导致严重的问题。
最后修改时间：2020-02-09 13:24:19
文章转载自
PostgreSQL中文社区，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
