使用sysbench测试阿里云RDS PostgreSQL性能

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云原生数据库 PolarDB MySQL 版,Serverless 5000PCU 100GB
云服务器 ECS,每月免费额度200元 3个月
简介: 测试PostgreSQL数据库性能的方法很多,例如pgbench, sysbench。sysbench因为使用lua脚本编程,支持多线程,灵活度更高,测试复杂的业务逻辑建议用sysbench。pgbench其实也很好,纯C写的,本身的开销小,测高并发低延迟的场景建议用pgbench。 首先要购

测试PostgreSQL数据库性能的方法很多,例如pgbench, sysbench。
sysbench因为使用lua脚本编程,支持多线程,灵活度更高,测试复杂的业务逻辑建议用sysbench。
pgbench其实也很好,纯C写的,本身的开销小,测高并发低延迟的场景建议用pgbench。

首先要购买RDS PG数据库实例
创建数据库用户
还需要购买同机房,与RDS PG同VPC网络ECS或者同经典网络的ECS
在ECS端安装PostgreSQL客户端

useradd digoal
su - digoal

wget https://ftp.postgresql.org/pub/source/v9.5.2/postgresql-9.5.2.tar.bz2
tar -jxvf postgresql-9.5.2.tar.bz2
cd postgresql-9.5.2
./configure --prefix=/home/digoal/pgsql9.5
gmake world -j 16
gmake install-world -j 16

vi ~/env_pg.sh
export PS1="$USER@`/bin/hostname -s`-> "
export PGPORT=1921
export LANG=en_US.utf8
export PGHOME=/home/digoal/pgsql9.5
export LD_LIBRARY_PATH=$PGHOME/lib:/lib64:/usr/lib64:/usr/local/lib64:/lib:/usr/lib:/usr/local/lib:$LD_LIBRARY_PATH
export DATE=`date +"%Y%m%d%H%M"`
export PATH=$PGHOME/bin:$PATH:.
export MANPATH=$PGHOME/share/man:$MANPATH
export PGHOST=$PGDATA
export PGUSER=postgres
export PGDATABASE=postgres
alias rm='rm -i'
alias ll='ls -lh'
unalias vi

. ~/env_pg.sh

安装sysbench

cd ~
mkdir sysbench
cd sysbench

git clone https://github.com/digoal/sysbench.git

cd sysbench
gcc -o gendata gendata.c

初始化测试数据

./sysbench_pg --test=lua/parallel_init_pg.lua \
  --db-driver=pgsql \
  --pgsql-host=xxx.xxx.xxx.xxx \
  --pgsql-port=3432 \
  --pgsql-user=digoal \
  --pgsql-password=pwd \
  --pgsql-db=postgres \
  --oltp-tables-count=16 \
  --oltp-table-size=1000000 \
  --num-threads=16 \
  cleanup


./sysbench_pg --test=lua/parallel_init_pg.lua \
  --db-driver=pgsql \
  --pgsql-host=xxx.xxx.xxx.xxx \
  --pgsql-port=3432 \
  --pgsql-user=digoal \
  --pgsql-password=pwd \
  --pgsql-db=postgres \
  --oltp-tables-count=16 \
  --oltp-table-size=1000000 \
  --num-threads=16 \
  run

测试oltp_pg.lua的内容,包含SQL如下,其中第一条SQL循环10次 :

   -- select c from tbl where id = $1;
   -- select id,k,c,pad from tbl where id in ($1,...$n);
   -- select c from tbl where id between $1 and $2;
   -- select sum(k) from tbl where id between $1 and $2;
   -- select c from tbl where id between $1 and $2 order by c;
   -- select distinct c from tbl where id between $1 and $2 order by c;
   -- update tbl set k=k+1 where id = $1;
   -- update tbl set c=$2 where id = $1;
   -- delete from tbl where id = $1;
   -- insert into tbl(id, k, c, pad) values ($1,$2,$3,$4);

一个事务执行19条SQL。

./sysbench_pg --test=lua/oltp_pg.lua \
  --db-driver=pgsql \
  --pgsql-host=xxx.xxx.xxx.xxx \
  --pgsql-port=3432 \
  --pgsql-user=digoal \
  --pgsql-password=pwd \
  --pgsql-db=postgres \
  --oltp-tables-count=16 \
  --oltp-table-size=1000000 \
  --num-threads=16 \
  --max-time=120  \
  --max-requests=0 \
  --report-interval=1 \
  run

OLTP test statistics:
    queries performed:
        read:                            0
        write:                           0
        other:                           566572
        total:                           566572
    transactions:                        26972  (224.62 per sec.)
    deadlocks:                           0      (0.00 per sec.)
    read/write requests:                 0      (0.00 per sec.)
    other operations:                    566572 (4718.32 per sec.)

General statistics:
    total time:                          120.0791s
    total number of events:              26972
    total time taken by event execution: 1919.7217s
    response time:
         min:                                 39.35ms
         avg:                                 71.17ms
         max:                               3159.62ms
         approx.  95 percentile:             124.54ms

Threads fairness:
    events (avg/stddev):           1685.7500/85.94
    execution time (avg/stddev):   119.9826/0.02



下面是本次测试的瓶颈分析
连接到阿里云RDS管控平台,观察压测时间段的资源开销,哪个到了瓶颈就升级哪个资源。
如果是网络的问题,可以增加测试的并发来提升TPS。
因为单个会话的链路延迟已经是没法降低的。
关于链路延迟量化分析的文章可参考
https://yq.aliyun.com/articles/35176

RDS PG的优化手段

alter role all set random_page_cost=1.2;
alter role all set synchronous_commit=off;

因为RDS链路较长,延迟会比本地延迟大很多。
但是如何量化这个延迟呢?
因为rds pg数据库服务器我们没法用qperf来测试,所以需要借助数据库本身来测试延迟。

alter role all set random_page_cost=1.2;  
alter role all set synchronous_commit=off;  

重连数据库,测试数据库本身处理SQL的RT

create table test(crt_time timestamp);  

do language plpgsql 
$$

declare
begin
  for i in 1..10000 loop
    insert into test values (clock_timestamp());
  end loop;
end;

$$
;

postgres=> select avg(rt) from (select lead(extract(microseconds from crt_time)) over (order by crt_time)-extract(microseconds from crt_time) rt from test) t;
       avg        
------------------
 10.1338133813381
(1 row)

数据库处理RT平均约10微秒。
创建用于测试网络RT的函数。

create or replace function f() returns void as 
$$

  insert into test values(clock_timestamp());  

$$
 language sql;  

清除数据

truncate test;  

在ECS主机上创建测试脚本

vi test.sql
select f();

压测

export PGPASSWORD=pwd; pgbench -M prepared -n -r -P 1 -f ./test.sql -c 1 -j 1 -T 10 -h xxx.xxx.xxx.xxx -p 3432 -U digoal postgres
tps = 197.976441 (including connections establishing)

计算RT

postgres=> select avg(rt) from (select lead(extract(microseconds from crt_time)) over (order by crt_time)-extract(microseconds from crt_time) rt from test) t;
       avg        
------------------
 5045.96513390601  
(1 row)

扣除数据库自身处理开销10微秒,网络的RT约5.036毫秒。
延迟不小。

使用并发可以弥补这个链路延迟的短板问题,例如开启300个并发,再次测试。

truncate test;  
export PGPASSWORD=pwd; pgbench -M prepared -n -r -P 1 -f ./test.sql -c 300 -j 300 -T 10 -h xxx.xxx.xxx.xxx -p 3432 -U digoal postgres
tps = 27368.404844 (including connections establishing)
postgres=> select avg(rt) from (select lead(extract(microseconds from crt_time)) over (order by crt_time)-extract(microseconds from crt_time) rt from test) t;
       avg        
------------------
 37.5476444551323
(1 row)

吞吐量上来了,但是单个事务的RT还是摆在那里的。
另外一点,使用云数据库,建议多用UDF,减少应用程序和数据库的交互次数,从而缩短整个业务逻辑的响应时间。

相关实践学习
一小时快速掌握 SQL 语法
本实验带您学习SQL的基础语法,快速入门SQL。
7天玩转云服务器
云服务器ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,可降低 IT 成本,提升运维效率。本课程手把手带你了解ECS、掌握基本操作、动手实操快照管理、镜像管理等。了解产品详情: https://www.aliyun.com/product/ecs
相关文章
|
23小时前
|
缓存 关系型数据库 MySQL
|
1天前
|
存储 SQL 关系型数据库
关系型数据库mysql的性能与灵活性
【6月更文挑战第12天】关系型数据库mysql的性能与灵活性
48 1
|
5天前
|
缓存 关系型数据库 MySQL
如何优化MySQL 8.0的性能?
【6月更文挑战第14天】如何优化MySQL 8.0的性能?
22 5
|
8天前
|
关系型数据库 数据管理 数据库
数据管理DMS产品使用合集之如何极速恢复RDS(关系型数据库服务)中的数据表
阿里云数据管理DMS提供了全面的数据管理、数据库运维、数据安全、数据迁移与同步等功能,助力企业高效、安全地进行数据库管理和运维工作。以下是DMS产品使用合集的详细介绍。
|
12天前
|
关系型数据库 分布式数据库 数据库
PolarDB产品使用合集之可以使用什么来查看查询的执行计划和性能信息
PolarDB是阿里云推出的一种云原生数据库服务,专为云设计,提供兼容MySQL、PostgreSQL的高性能、低成本、弹性可扩展的数据库解决方案,可以有效地管理和优化PolarDB实例,确保数据库服务的稳定、高效运行。以下是使用PolarDB产品的一些建议和最佳实践合集。
|
15天前
|
关系型数据库 MySQL SQL
MySQL的 where 1=1会不会影响性能?
在MySQL动态SQL中,使用`where 1=1`主要目的是简化动态条件的拼接,有人担心这可能影响性能。然而,通过官方文档和实际测试发现,由于MySQL的Constant-Folding Optimization(常量折叠优化),`where 1=1`在大多数情况下会被优化掉,对性能影响微乎其微。MyBatis提供了`<where>`标签,能更有效地处理动态SQL,避免多余的`AND`或`OR`。当MySQL版本大于等于5.7时,两者性能差异不大,选择哪种方式可根据团队规范和个人喜好。而在旧版本中,如果使用MyBatis,推荐使用`<where>`标签。
|
24天前
|
负载均衡 关系型数据库 分布式数据库
【PolarDB开源】PolarDB读写分离实践:优化读取性能与负载均衡策略
【5月更文挑战第26天】PolarDB是云原生关系型数据库,通过读写分离优化性能和扩展性。它设置主节点处理写操作,从节点处理读操作,异步复制保证数据一致性。优化读取性能的策略包括增加从节点数量、使用只读实例和智能分配读请求。负载均衡策略涉及基于权重、连接数和地理位置的分配。实践示例中,电商网站通过主从架构、只读实例和负载均衡策略提升商品查询效率。PolarDB的读写分离与负载均衡为企业应对大数据和高并发提供了有效解决方案。
136 0
|
26天前
|
关系型数据库 分布式数据库 数据库
【阿里云云原生专栏】云原生时代的数据库选型:阿里云RDS与PolarDB对比分析
【5月更文挑战第24天】阿里云提供RDS和PolarDB两种数据库服务。RDS是高性能的在线关系型数据库,支持MySQL等引擎,适合中小规模需求;而PolarDB是分布式数据库,具备高扩展性和性能,适用于大规模数据和高并发场景。RDS与PolarDB在架构、性能、弹性伸缩、成本等方面存在差异,开发者应根据具体需求选择。示例代码展示了如何通过CLI创建RDS和PolarDB实例。
584 0
|
27天前
|
缓存 关系型数据库 MySQL
如何优化MySQL性能?
【5月更文挑战第23天】如何优化MySQL性能?
36 1
|
27天前
|
SQL 关系型数据库 数据库
阿里云数据库 RDS SQL Server版实战【性能优化实践、优点探析】
本文探讨了Amazon RDS SQL Server版在云数据库中的优势,包括高可用性、可扩展性、管理便捷、安全性和成本效益。通过多可用区部署和自动备份,RDS确保数据安全和持久性,并支持自动扩展以适应流量波动。可视化管理界面简化了监控和操作,而数据加密和访问控制等功能保障了安全性。此外,弹性计费模式降低了运维成本。实战应用显示,RDS SQL Server版能有效助力企业在促销高峰期稳定系统并保障数据安全。阿里云的RDS SQL Server版还提供了弹性伸缩、自动备份恢复、安全性和高可用性功能,进一步优化性能和成本控制,并与AWS生态系统无缝集成,支持多种开发语言和框架。
169 2

热门文章

最新文章