? ? ? ? ?这几天，在写一个关于PGSQL性能的测试报告。
? ? ? ? 今天找了台顶配的R710做测试。R710配置如下：E5-2650 v2两颗，128G内存，磁盘为两块SATA盘做RAID0 拼出来的一个T的磁盘。
? ? ? ? 之前同事在上面测试mysql的QPS大概是20W多，具体不详。
? ? ? ? 本着简单试试的想法，源码编译安装了pgsql，pgsql的配置如下：
? ? ? ? ?
max_connections = 512shared_buffers = 30720MBmaintenance_work_mem = 512MBvacuum_cost_delay = 10vacuum_cost_limit = 10000 # 1-10000 creditsbgwriter_delay = 10ms # 10-10000ms between roundsbgwriter_lru_maxpages = 1000 # 0-1000 max buffers written/roundwal_level = hot_standby wal_writer_delay = 10ms # 1-10000 millisecondscheckpoint_segments = 256 # in logfile segments, min 1, 16MB eachcheckpoint_timeout = 10min # range 30s-1
? ?基本上都是经验值。shared_buffer设置主要是根据建议设置为内存的20%上下
?
? ?然后使用pgbenc生成了大概60个G的数据：
pgbench -i -s 4000
? ?结果按照如下方式直接运行pgbench,
?
?
pgbench -S -M prepared -c N -j N -T 60 postgres
其中：-S选项指定只执行select，也就是只执行
SELECT abalance FROM pgbench_accounts WHERE aid = $1
?这样的SQL，pebench_acounts是一张代表，对应一个星形模型中的那个大表，里面被插入了4KW条数据，表的主键是aid这个字段，查询的参数是随机生成的；-M prepared是使用预编译的方式执行SQL,避免重复解析SQL；N是连接数和模拟的客户端，在这里是每个客户端使用一个连接；?-T 60指定连续执行60秒。
在启动数据库之后，先用上面的命令运行了300秒，来预热数据。然后再进行实际的测试
最后发现N在128之后，增大N无法明显获得更大的QPS，如是将N设置为128。但是跑出来的结果让人感觉还行，快20W了：
?
查看了磁盘的IO，发现不断的有读的请求，于是直接查看数据数据库的block命中率，发现命中率不高，不到90%：
?感觉主要是没有缓存住所有热数据，有潜力可挖，于是试着将shared_buffer调整到了50G继续测试，QPS到了26W，而命中率也到了96%。但是，发现IO还是偶尔会达到10M/s。
? 于是，将shared_buffer调整到了60G，这基本上应该能缓存住所有的数据了。结果TPS到了34W多，命中率也到了快100%：
?明显，这个已经是最理想的情况了。数据都在shared buffer里面了。如果还要进一步的提高QPS，则需要更多更强的CPU了。当然，继续调高shared buffer也没有必要了，因为实际的数据就只有60G了。
? ?另外，拿着update和insert操作测试过，数据不是很理想，主要是因为瓶颈在IO能力上，毕竟SATA盘距离实际使用的SSD还是有不小距离的，这里就不贴了。
?
?
?
?