0

用Benchmark压测PostgreSQL测试

白鳝的洞穴 2020-06-18
2142
在我们学习数据库或者开发数据库监控软件的时候,经常需要给数据库加压。benchmark本身不是为了这个目的开发的,不过经过我们简单的调整,Benchmark工具也可以成为我们身边的好帮手。
经过简单的配置,目前我们使用benchmark为Oracle、达梦、金仓、华为高斯、Postgres等数据库加压。
最近这段时间,为了验证PG的性能与负载模型,需要对PG库进行加压。老白就简单的使用Benchmark工具就开始工作了。
首先配置一下props文件,把props.pg打开,进行修改:

上面这组参数是为TPC-C标准设置的,通过调整权重可以模拟不同类型的负载。
系统不大,所以我们设置100个wharehouse,启动200个终端,最大TPM设置为90万,系统配置不高,90万很难达到。改完PROPS文件,就开始创建基准测试环境:

build的时候负载不高:

    PG库的健康分在80分,性能分在81分。

BUILD好BENCHMARK测试环境后,下面我们就可以开始测试了。可以逐步加压,首先我们限制TPM在10万以内.进行第一轮测试:

从PG服务器上看,负载一般:

从负载模型和性能模型上看:

性能与负载都属于B类。属于较高负载,正常的性能。
第二步放开TPM限制。再次进行压测。

几分钟后,TPM稳定在18万多,此时OS的负载已经很高了:

PG数据库的健康指标与性能指标也出现了较大的下降。

从负载指标上看,REDO的量是相当高的,达到每秒近100M,逻辑读的量大约132万,物理读都很小,因为TPCC测试的数据相对命中率比较高。活跃会话数达到200多。每秒更新行数达到3万多,插入行数1.6万,扫描行数194万。相对于其他数据库的BENCHMARK测试,PG的REDO量是最高的,其他数据库一般都在10M以内。这和PG的REDO机制和MVCC实现机制有很大的关系。从这个简单的测试也可以看出,如果要让PG数据库跑的好,WAL日志需要存放在性能较好的磁盘上,否则WAL可能成为瓶颈。
这时候我去访问这个PG实例的其他数据库,已经发现系统有点慢了,看样子系统的整体性能已经出现了问题。系统性能分79分也从另外一个侧面反映了系统的性能问题。
不过虽然负载与性能的变化能够被模型反馈出来,不过模型的反馈还不够灵敏,后续模型还有继续优化的余地。
我们通过健康、负载、性能三个模型来对数据库系统进行分析。健康模型更关注系统的健康有关的情况,比如系统是否存在宕机、停服、HANG死等的风险,不同配置的系统,健康判断的标准需要有所不同;负载模型是一个客观模型,不管你的系统的配置如何,用一套负载标准去判断负载属于哪一类;性能模型一定是基于负载的,不同的负载下,性能反馈也会有所不同。
目前的Benchmark工具对Mysql的支持不好,以前benchmark也支持mysql不过经常测试出来的结果不是很好。实际上benchmark工具是一组通用的工具,不考虑针对某个数据库进行优化,因此极限的TPC-C测试的效果往往不尽如人意,很多数据库厂商在测试数据库性能的时候都会用自己改造优化过的BENCHMARK工具。这种测试的结果往往是受到最多诟病的。实际上现在服务器的能力十分强大,单一数据库的TPCC测试结果意义不大。最近5-10年里,送测TPCC的厂家凤毛麟角,大多数都是天朝或者韩国的厂商,其他数据库厂家已经不太关注TPCC这个军备竞赛年代的指标了。对于大多数用户来说,如何更好的支撑应用系统,让系统运维变得更简单,可能比单纯的TPCC有价值的多。
最后修改时间:2021-07-28 11:59:18
「喜欢文章,快来给作者赞赏墨值吧」
文章转载自白鳝的洞穴,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论

关注
最新发布
暂无内容,敬请期待...
数据库资讯
最新 热门 更多
本月热门
近期活动
全部
暂无活动,敬请期待...
相关课程
全部