任务目标:
NO 1 :利用工具对postgresql数据库进行压力检测,关注不同并发数下的同步效率,
NO 2 :记录过程中网络时延、不同并发下的TPS、资源使用情况以及对应的主从同步情况,
NO 3 :模拟异常检查主从数据一致性。
工作环境及工具:
redhat 7.4 || postgresql || psql || pgbench || nmon
Linux操作系统:常见的生产环境不做过多介绍。
PostgreSQL: PostgreSQL是一个功能强大的开源对象关系数据库管理系统(ORDBMS)。 用于安全地存储数据; 支持最佳做 法,并允许在处理请求时检索它们。由PostgreSQL全球开发集团(全球志愿者团队)开发。 它不受任何公司 或 其他私人实体控制。它是开源的,其 源代码是免费提供的。PostgreSQL是跨平台的,可以在许多操作系 统 上运 行,如Linux,OS X和Microsoft Windows等。
postgresql与MySQL之间的比较,不做赘述,各持己见。
psql:命令行工具,也是管理PostgreSQL的主要工具
pgbench:pgbench 是一个方便的pg 性能测试工具,具体安装和指令参数操作不做赘述。
nmon: Nmon ( 又名 Nigel’s Monitor) 是非常常用的系统性能监视工具,由 IBM 工程师 Nigel Griffiths 开发,适用于 AIX 和 Linux 操作系统。该工具可以直接在屏幕上显示当前操作系统的资源利用率,以帮助大家找出系统瓶颈和协助系统调优。
Action:
在登录上主机数据库(ssh远程连接)。
1. 在测试主机准备测试数据库。
pgbench -i --unlogged-tables -s 2 -U postgres -p 5432 -d pgbench -h localhost
一般情况下都能成功
效果
pgbench -i --unlogged-tables -s 2 -U postgres -p 5432 -d postgres -h localhost
NOTICE: table "pgbench_history" does not exist, skipping
NOTICE: table "pgbench_tellers" does not exist, skipping
NOTICE: table "pgbench_accounts" does not exist, skipping
NOTICE: table "pgbench_branches" does not exist, skipping
creating tables...
100000 of 200000 tuples (50%) done (elapsed 0.03 s, remaining 0.03 s)
200000 of 200000 tuples (100%) done (elapsed 0.06 s, remaining 0.00 s)
vacuum...
set primary keys...
done.
pgbench -i --unlogged-tables -s 16 -U postgres -p 5432 -h localhost -d postgres
creating tables...
100000 of 1600000 tuples (6%) done (elapsed 0.03 s, remaining 0.42 s)
200000 of 1600000 tuples (12%) done (elapsed 0.06 s, remaining 0.40 s)
300000 of 1600000 tuples (18%) done (elapsed 0.09 s, remaining 0.37 s)
400000 of 1600000 tuples (25%) done (elapsed 0.14 s, remaining 0.41 s)
500000 of 1600000 tuples (31%) done (elapsed 0.17 s, remaining 0.37 s)
600000 of 1600000 tuples (37%) done (elapsed 0.20 s, remaining 0.33 s)
700000 of 1600000 tuples (43%) done (elapsed 0.23 s, remaining 0.29 s)
800000 of 1600000 tuples (50%) done (elapsed 0.25 s, remaining 0.25 s)
900000 of 1600000 tuples (56%) done (elapsed 0.28 s, remaining 0.22 s)
1000000 of 1600000 tuples (62%) done (elapsed 0.31 s, remaining 0.19 s)
1100000 of 1600000 tuples (68%) done (elapsed 0.42 s, remaining 0.19 s)
1200000 of 1600000 tuples (75%) done (elapsed 0.52 s, remaining 0.17 s)
1300000 of 1600000 tuples (81%) done (elapsed 0.75 s, remaining 0.17 s)
1400000 of 1600000 tuples (87%) done (elapsed 0.96 s, remaining 0.14 s)
1500000 of 1600000 tuples (93%) done (elapsed 1.15 s, remaining 0.08 s)
1600000 of 1600000 tuples (100%) done (elapsed 1.55 s, remaining 0.00 s)
vacuum...
set primary keys...
done.
结果查询如下:生成了四个测试表
执行压力测试
pgbench -M prepared -r -c 500 -j 500 -T 600 -U postgres -h localhost -p 5432 -d pgbench -l
参数说明
以上参数中,-M prepared表示绑定变量形式的调用SQL,-r表示报告测试文件中每条SQL的平均执行延迟,
-c 500表示模拟500个客户端,-j 500表示pgbench的工作线程是500个,
-T 600表示压力测试的时间是10分钟,-l表示把事务统计写入log,其余的是postgres连接相关的参数
以上参数,也可以结合命令帮助看出来
执行结果
此处可以看到这个tps是相当的低啊。500X500的并发量下。
借助nmon工具 进行资源情况的查看
-d 磁盘情况的查看
网络时延的查看,主从互ping
数据主从同步情况的查看需要在psql命令下同时执行查询数量
select count(*)from pgbench_histroy
采取了多个数据检测点进行抽样。
这么看来数据统一量在误差范围之内。到此检测完毕。那么其中的问题来了:
问题1 如何设置最高连接数,因为postgresql允许最大连接数为1000,
连接PG报错:“sorry,too many clients already. ”
修改操作如下:
1.合适的最大连接数
used_connections/max_connections在85%左右
2.修改最大连接数
postgresql最大连接数默认为100
1)打开postgresql配置文件
vim /var/lib/pgsql/9.4/data/postgresql.conf
2)修改最大连接数
max_connections = 100
3)重启postgresql服务
在CentOS 6.x系统中
service postgresql-9.4 restart
在CentOS 7系统中
systemctl restart postgresql-9.4
问题2;处理的并发量太大,修改的问题一还是不行怎么办?
超过1000个连接会报错如下
invalid number of clients
为了解决这个问题我在全网搜索了一下,众多博客都是来源于以下答案,现将原文po下
《PostgreSQL pgbench 支持100万连接 》
https://yq.aliyun.com/articles/603293
异常下的检测:
步骤一:将主机执行压力检测,过程中将数据库进程kill掉,
步骤二:此刻查看从机的数据同步量并记录,之后正常停止服务。
systemctl stop postgresql ,
步骤三:开启主机数据库服务,查看数据库表中数据量,检测与从机数据差异。
文章至此任务完成。有其他问题欢迎探讨。
现贴以下参考文档:
pgSQL学习手册:https://www.cnblogs.com/stephen-liu74/archive/2012/06/06/2312759.html
psql使用技巧:https://www.cnblogs.com/ryanzheng/p/9575902.html
pgbench安装使用:https://www.cnblogs.com/rongfengliang/p/10459650.html
nmon检测性能:https://zhidao.baidu.com/question/1863288736852021747.html
科学增加pg连接数:https://www.cnblogs.com/xiangnan/p/10051240.html