使用ScaleFlux公司的csd2000卡大幅提升PostgreSQL性能__本文详细讲解了把fillfactor参数调整到70%时，使用csd2000的透明压缩功能让实际占用空间很少增长的情况下（增长8%），让pgbench测试出来的性能提升近40%。同时使用了csd2000的透明压缩功能让空间占用率到达了原空间的六分之一，大大的节省了空间。: 世界上功能最强大的开源数据库...

作者介绍

唐成: 网名 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的功能，删除一个大文件，实际占用的空间不会释放，这会导致严重的问题。

CENTER_PostgreSQL_Community

### **作者介绍**

### **1. 文章介绍**

### **2. 测试场景**

最近听说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的测试**

理论归理论，还是看我们的实测，看看实际的效果如何：
```
[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. 测试结论**

### **5. 关于使用空间的监控**
有人问实际空间3.2T，做成了9.6T的卡，是否会出现当压缩率没有3倍这么高时，实际的空间没有了，但显示还有很多空闲空间还可以使用的情况，从而导致严重的问题？这个问题是不会出现的，ScaleFlux公司已经想到了这个问题，装完他们卡的整个驱动程序后内部有一个容量管理的程序，这个程序会让“df -h”看到的空间占用率是准确的，当实际的空间占用率到达80%时，通过“df -h”看到的空间占用率也是正确的80%，这样监控程序就可以准确告警出来，不会导致空间满而没有发现的问题。不过这里需要注意，不能把csd2000的盘用LVM管理，否则就无法正确使用容量管理程序的这个功能了。另在mount盘时一定要加上“discard”选项，如类似下面这样：
```
mount -o discard /dev/sfdv0n1 /data
```
否则没有了trim的功能，删除一个大文件，实际占用的空间不会释放，这会导致严重的问题。

![CENTER_PostgreSQL_Community](/images/news/2016/pg_bot_banner.jpg)