PostgreSQL OLTP高并发请求性能优化

本文涉及的产品
云原生数据库 PolarDB MySQL 版,Serverless 5000PCU 100GB
云原生数据库 PolarDB 分布式版,标准版 2核8GB
云数据库 RDS MySQL Serverless,0.5-2RCU 50GB
简介:
在多核系统中,一般TPS会随并发数的增加而提升,但是当并发数超过一定的数值(如CPU核数的2到3倍以后),性能开始下降,并发数越高,下降越严重。
例子:
更新500万记录表中的1条随机记录。开8000个并发。
create table test_8000 (id int primary key, cnt int default 0);
insert into test_8000 select generate_series(1,5000000);

vi t.sql
\setrandom id 1 5000000
update test_8000 set cnt=cnt+1 where id=:id;
update test_8000 set cnt=cnt+2 where id=:id;
每次加载80个并发,循环100次,一共加载8000个并发。
vi test.sh
#!/bin/bash
for ((i=0;i<100;i++))
do

sleep 1;
pgbench -M simple -n -r -f ./t.sql -c 80 -j 80 -T 100000 -U postgres &

done
开始
. ./test.sh
当连接数达到8000后,观察TPS,我们可以使用PG的统计信息表来计算QPS。
postgres=# select count(*) from pg_stat_activity;
 count 
-------
  8002
(1 row)

postgres=# select timestamptz '2015-10-08 17:01:24.203089+08' - timestamptz '2015-10-08 17:01:16.574076+08';
    ?column?     
-----------------
 00:00:07.629013
(1 row)

postgres=# select 43819090-43749480;
 ?column? 
----------
    69610
(1 row)

postgres=# select 69610/07.629013;
       ?column?        
-----------------------
 9124.3782124896103860
(1 row)
8000个并发的时候,更新TPS约9124。大部分时间可能浪费在CPU调度上了。

另一种场景,
如果有8000个并发是空闲连接,只有10个在执行更新,性能是这样的:
先制造8000个空闲连接:
vi test.sql
select pg_sleep(100000);

vi test.sh
#!/bin/bash
for ((i=0;i<100;i++))
do

sleep 1;
pgbench -M simple -n -r -f ./test.sql -c 80 -j 80 -T 100000 -U postgres &

done

. ./test.sh

postgres=# select count(*) from pg_stat_activity;
 count 
-------
  8002
(1 row)
然后开启10个连接执行更新操作。
pgbench -M prepared -n -r -f ./t.sql -P 1 -c 10 -j 10 -T 1000 -U postgres postgres
progress: 1.0 s, 29429.2 tps, lat 0.336 ms stddev 0.109
progress: 2.0 s, 28961.1 tps, lat 0.343 ms stddev 0.114
progress: 3.0 s, 30433.8 tps, lat 0.326 ms stddev 0.103
progress: 4.0 s, 29597.1 tps, lat 0.336 ms stddev 0.114
progress: 5.0 s, 28714.1 tps, lat 0.346 ms stddev 0.117
progress: 6.0 s, 28319.0 tps, lat 0.351 ms stddev 0.121
progress: 7.0 s, 28540.0 tps, lat 0.348 ms stddev 0.118
progress: 8.0 s, 29408.9 tps, lat 0.338 ms stddev 0.111
progress: 9.0 s, 29178.1 tps, lat 0.340 ms stddev 0.119
progress: 10.0 s, 29146.9 tps, lat 0.341 ms stddev 0.118
progress: 11.0 s, 27498.5 tps, lat 0.361 ms stddev 0.123
这种方法的性能约6万 qps。

优化思路:
排队处理用户请求。类似pgbouncer或Oracle的shared server机制,真实处理请求的进程数有限。

使用PostgreSQL的advisory函数可以模拟这种排队机制:
create or replace function upd(l int,v_id int) returns void as 
$$

declare
begin
  LOOP
    if pg_try_advisory_xact_lock(l) then  -- 只有获得这个应用级锁才执行更新,否则就等待。
      update test_8000 set cnt=cnt+1 where id=v_id;
      update test_8000 set cnt=cnt+2 where id=v_id;
      return;
    else
      perform pg_sleep(30*random());  --  随机等待时间
    end if;
  END LOOP;
end;

$$
 language plpgsql strict;

增加一个随机变量l,用来表示应用所的号码,也就是说模拟10个同时在更新的操作,其他的都在等待。
这个是没有经过优化的排队机制,因为不是独立的进程处理用户请求,依旧是backend process在处理用户请求,依旧有8000个进程。
vi t.sql
\setrandom id 1 5000000
\setrandom l 1 10
select upd(:l, :id);

vi test.sh
#!/bin/bash
for ((i=0;i<100;i++))
do

sleep 1;
pgbench -M simple -n -r -f ./t.sql -c 80 -j 80 -T 100000 -U postgres &

done

. ./test.sh
测试结果比较理想,已经提升了1倍性能。
postgres=# select now(),n_tup_upd+n_tup_hot_upd from pg_stat_all_tables where relname='test_8000';
              now              | ?column?  
-------------------------------+-----------
 2015-10-08 19:06:37.951332+08 | 221045069
(1 row)

postgres=# select now(),n_tup_upd+n_tup_hot_upd from pg_stat_all_tables where relname='test_8000';
             now              | ?column?  
------------------------------+-----------
 2015-10-08 19:07:46.46325+08 | 222879057
(1 row)

postgres=# select timestamptz '2015-10-08 19:07:46.46325+08' - timestamptz '2015-10-08 19:06:37.951332+08';
    ?column?     
-----------------
 00:01:08.511918
(1 row)

postgres=# select 222879057-221045069;
 ?column? 
----------
  1833988
(1 row)

postgres=# select 1833988/68.5;
      ?column?      
--------------------
 26773.547445255474
(1 row)
模拟结果,相比不排队,有1倍以上的性能提升。  
TOP
top - 19:09:37 up 119 days,  3:59,  2 users,  load average: 0.96, 0.98, 1.01
Tasks: 8872 total,   5 running, 8866 sleeping,   1 stopped,   0 zombie
Cpu(s):  5.3%us,  0.8%sy,  0.0%ni, 93.9%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  132124976k total, 118066688k used, 14058288k free,   316752k buffers
Swap:  2097144k total,      148k used,  2096996k free, 63702028k cached

advisory lock是PG提供的一种轻量级的面向用户的锁(当然比LWLOCK是要重的),我之前在秒杀场景的优化中也有叙述,可以达到每秒处理19万次的单条记录更新请求的性能,并且保持1毫秒以内的RT。请参考。
http://blog.163.com/digoal@126/blog/static/16387704020158149538415/

把这种优化思路加入到PostgreSQL的内核中是比较靠谱的,最终实现的效果会和Oracle的shared server非常类似。
阿里云PG内核组的小鲜肉和老腊肉们,优化开始搞起吧。
在没有优化前,还是使用pgbouncer这种连接池吧。

[参考]
1. http://blog.163.com/digoal@126/blog/static/16387704020158149538415/
相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
相关文章
|
4月前
|
消息中间件 NoSQL Java
Java高级开发:高并发+分布式+高性能+Spring全家桶+性能优化
Java高架构师、分布式架构、高可扩展、高性能、高并发、性能优化、Spring boot、Redis、ActiveMQ、Nginx、Mycat、Netty、Jvm大型分布式项目实战学习架构师之路
|
5月前
|
消息中间件 缓存 负载均衡
高并发与性能优化的神奇之旅
高并发与性能优化的神奇之旅
|
2月前
|
缓存 安全 API
【亿级数据专题】「高并发架构」盘点本年度探索对外服务的百万请求量的API网关设计实现
公司对外开放的OpenAPI-Server服务,作为核心内部系统与外部系统之间的重要通讯枢纽,每天处理数百万次的API调用、亿级别的消息推送以及TB/PB级别的数据同步。经过多年流量的持续增长,该服务体系依然稳固可靠,展现出强大的负载能力。
55 9
【亿级数据专题】「高并发架构」盘点本年度探索对外服务的百万请求量的API网关设计实现
|
7月前
|
缓存 NoSQL 中间件
redis如何通过读写分离来承载读请求高并发
redis如何通过读写分离来承载读请求高并发
64 0
|
2月前
|
存储 消息中间件 Java
【亿级数据专题】「高并发架构」盘点本年度探索对外服务的百万请求量的高可靠消息服务设计实现
在深入研究了 **“【亿级数据专题】「高并发架构」盘点本年度探索对外服务的百万请求量的API网关设计实现”** 设计实现后,我们意识到,尽管API网关为服务商提供了高效的数据获取手段,但实时数据的获取仍然是一个亟待解决的问题。
26 1
【亿级数据专题】「高并发架构」盘点本年度探索对外服务的百万请求量的高可靠消息服务设计实现
|
8月前
|
关系型数据库 分布式数据库 数据库
沉浸式学习PostgreSQL|PolarDB 2: 电商高并发秒杀业务、跨境电商高并发队列消费业务
业务场景介绍: 高并发秒杀业务 秒杀业务在电商中最为常见, 可以抽象成热点记录(行)的高并发更新. 而通常在数据库中最细粒度的锁是行锁, 所以热门商品将会被大量会话涌入, 出现锁等待, 甚至把数据库的会话占满, 导致其他请求无法获得连接产生业务故障. 业务场景介绍: 高并发队列消费业务 在跨境电商业务中可能涉及这样的场景, 由于有上下游产业链的存在, 1、用户下单后, 上下游厂商会在自己系统中生成一笔订单记录并反馈给对方, 2、在收到反馈订单后, 本地会先缓存反馈的订单记录队列, 3、然后后台再从缓存取出订单并进行处理.
320 1
|
8月前
|
关系型数据库 测试技术 分布式数据库
PolarDB | PostgreSQL 高并发队列处理业务的数据库性能优化实践
在电商业务中可能涉及这样的场景, 由于有上下游关系的存在, 1、用户下单后, 上下游厂商会在自己系统中生成一笔订单记录并反馈给对方, 2、在收到反馈订单后, 本地会先缓存反馈的订单记录队列, 3、然后后台再从缓存取出订单并进行处理. 如果是高并发的处理, 因为大家都按一个顺序获取, 容易产生热点, 可能遇到取出队列遇到锁冲突瓶颈、IO扫描浪费、CPU计算浪费的瓶颈. 以及在清除已处理订单后, 索引版本未及时清理导致的回表版本判断带来的IO浪费和CPU运算浪费瓶颈等. 本文将给出“队列处理业务的数据库性能优化”优化方法和demo演示. 性能提升10到20倍.
594 4
|
10月前
|
XML JSON 缓存
lazada获得lazada商品详情 API接口调用成功案例分享 返回数据解析(实时数据,支持高并发请求)
lazada获得lazada商品详情 API接口调用成功案例分享 返回数据解析(实时数据,支持高并发请求)
|
10月前
|
API
2023最全电商API接口 高并发请求 实时数据 支持定制 电商数据 买家卖家数据
2023最全电商API接口 高并发请求 实时数据 支持定制 电商数据 买家卖家数据
|
11月前
|
关系型数据库 PostgreSQL
PostgreSQL 性能优化: 等待事件
等待事件是 PostgreSQL 的重要优化工具。当您能查明会话为什么在等待资源以及会话在做什么时,您就能更好地减少瓶颈。您可以使用本节中的信息来查找可能的原因和纠正措施。
195 0

相关产品

  • 云原生数据库 PolarDB