文章转载自公众号: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资源负载: 从上面的信息可以