在我们学习数据库或者开发数据库监控软件的时候，经常需要给数据库加压。benchmark本身不是为了这个目的开发的，不过经过我们简单的调整，Benchmark工具也可以成为我们身边的好帮手。经过简单的配置，目前我们使用benchmark为Oracle、达梦、金仓、华为高斯、Postgres等数据库加压。最近这段时间，为了验证PG的性能与负载模型，需要对PG库进行加压。老白就简单的使用Benchmark工具就开始工作了。首先配置一下props文件，把props.pg打开，进行修改：
上面这组参数是为TPC-C标准设置的，通过调整权重可以模拟不同类型的负载。系统不大，所以我们设置100个wharehouse，启动200个终端，最大TPM设置为90万，系统配置不高，90万很难达到。改完PROPS文件，就开始创建基准测试环境：
PG库的健康分在80分，性能分在81分。
BUILD好BENCHMARK测试环境后，下面我们就可以开始测试了。可以逐步加压，首先我们限制TPM在10万以内.进行第一轮测试：
几分钟后，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进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
