postgresql 客户端_PostgreSQL上线优化案例QPS从500到上万级别压测之路

文章转载自公众号：DB印象

业务需求描述

要求每个事务逻辑延迟1秒以内，业务初期读写3000的QPS，后续有明星大咖空降活动，要求QPS能力可横向扩展。

注：这里说的读写3000的QPS，其实水有点坑。(详见后文)

系统架构环境

1.前端应用部署55台客户端设备，单台client机型配置8核心14G内存，程序使用golang+lib/pq实现编码。

2.DB侧使用pg分布式，单分片一主二从架构，可进行读写分离(后续有时间再补充独立分离的情况)：

1)写平面配置2个cn，机型8核14G虚拟机；

2)同城只读平面、异地只读平面各配置1个cn，8核14G虚拟机。

3)主备dn节点一主二从均为32核64G的物理机，SSD存储。

3.架构简图如下：

本次压测最终使用的链路如下: 1台client-->负载均衡-->1个cn-primary节点-->1个dn-primary节点

压测优化过程

业务层面设置每个tps为1秒强制超时，当tps达到500时业务出现大量超时报错，吐槽pg能力太差：

本次压测的SQL单次执行性能都在15ms以内，500并发请求业务层面就开始出现大量超时异常，打死也不能认了。 根本原因是前端应用使用的无上限短连接导致DB侧接入节点cn负载过高导致。 首先，暂且先保持这个无上限的短连接，将写平面2个cn节点替换成1台32核64G的物理机，使写平面变成1cn->1dn的关系，再看看QPS能去到多少。 再次压测，当DB侧QPS达到8400左右的时候，业务侧开始出现超时，DB侧cn节点CPU使用率接近100%：

接下来我们得拿短连接下刀，排查应用代码发现开发同学在程序里调用动态库时未配置SetMaxOpenConns()参数，该参数缺省为0，即短连接无上限。 将client连接数上限控制在32个，重新压测，DB侧QPS提升到1.2w左右，CPU使用率还有大半空余，但此时业务侧开始出现同样的超时报错：

cn资源负载：

dn资源负载：

从上