Oracle 19c RAC 不同架构下压测性能对比分析报告

1 背景描述

针对目前的某 Oracle 核心库升级到 19c 的项目，通过对不同架构下的 RAC 进行压力测试，最终确定升级后生产环境的架构选择。基于此目的，对于压测结果着重分析集群相关的指标。

2 压测方案说明

利用工具 Swingbench 进行测试，Swingbench 是一个免费的负载生成器和基准测试工具，其支持 Oracle 数据库（11g、12c、18c、19c），以前写过一篇压测工具的使用，感兴趣的可以戳此查看。Swingbench 的开发目的主要是展示 RAC 的负载和测试，也可用于单实例环境。Swingbench 模拟了一套订单业务逻辑，通过创建 SOE 用户，模拟产品和订单业务，然后自定义数据量 50G 的大小，本次测试生成 50GB 的业务数据，在准生产环境新 19c 物理机下模拟并发数为 5000 的并发测试。四台物理机版本和数据库配置如下：

192.16.75.131 和 192.16.75.132 位于同城 A 中心，利用存储双活技术，192.16.75.133 和 192.16.75.134 在距离不远的同城 B 中心，构建出一套基于补丁 RU15 的 19c 四节点 RAC。数据库参数也是根据最佳参数实践进行配置，具体参数可参考：https://www.modb.pro/doc/99630

四个压测方案分别为：

1)、生产环境使用同城双中心共 4 个节点的 RAC，IP 分别为192.16.75.131、192.16.75.132、192.16.75.133、192.16.75.134，进行连接数为 5000 并发压力测试，共计 50 分钟；

2)、生产环境使用同城 A 中心 2 个节点的 RAC，分别为 192.16.75.133、192.16.75.134，进行 5000 并发压力测试，共计 50 分钟；

3)、生产环境使用同城 A 中心、同城 B 中心各 1 个节点的 RAC，分别为192.16.75.131、192.16.75.133，进行 5000 并发压力测试，共计 50 分钟。

4)、生产环境使用同城 A 中心 2 个节点、同城 B 中心 1 个节点的 RAC，分别为192.16.75.131、192.16.75.132、192.16.75.134，进行 5000 并发压力测试，共计 50 分钟。

3 压测结果分析

3.1 双中心 4 节点 rac

测试时间 50 分钟，5000 并发会话连接，测试过程中观察到 TPS（吞吐量）、IOPS（每秒IO读写次数）、RT（响应时间）、CPU使用情况等数据，结果如下表：

另外针对数据库指标分析如下：

如上图总体资源利用率有倾斜，4 节点压力并不均匀,Swingbench 看来还是压测单节点比较好。

如上图集群相关等待事件汇总情况，平均等待 489,312.23 秒，总计 1,957,248.90 秒，占 DB time 的 14.24%。

如上图集群相关等待事件明细情况，4 节点压测时，在 top event 中共出现 8 种集群类等待事件，分别为 gc buffer busy acquire、gc current block busy、gc cr multi block mixed、gc cr block lost、gc cr block 3-way、gc cr block 2-way、gc current block lost、gc current grant 2-way。

3.2 同城 A中心 2 节点rac

测试时间 50 分钟，5000 并发会话连接，测试过程中观察到 TPS（吞吐量）、IOPS（每秒 IO 读写次数）、RT（响应时间）、CPU 使用情况、集群等待时间等数据，结果如下：

另外针对数据库指标分析如下：

如上图总体资源利用率，2 节点压力较均匀。

如上图集群相关等待事件汇总情况，平均等待 1,586,569.06 秒，总计3,173,138.13 秒，占 DB time 的 18.89%。

如上图集群相关等待事件明细情况，同城 A 中心 2 节点压测时，在 top event 中只出现 4 种集群类等待事件，分别为 gc buffer busy acquire、gc current block busy、gc cr block lost、gc cr block 2-way。

3.3 同城 A、同城 B 各 1 节点

测试时间 50 分钟，5000 并发会话连接，测试过程中观察到 TPS（吞吐量）、IOPS（每秒IO读写次数）、RT（响应时间）、CPU 使用情况等数据，结果如下：

另外针对数据库指标分析如下：

如上图总体资源利用率，2 节点压力较均匀。

如上图集群相关等待事件汇总情况，平均等待 4,263,328.07 秒，总计 8,526,656.15 秒，占 DB time 的 61.59%。

如上图集群相关等待事件明细情况，同城 A、同城 B 各 1 节点压测时，在 top event中出现了7种集群类等待事件，分别为gc buffer busy acquire、gc current block busy、gc cr block lost、gc cr block 2-way、gc current grant busy、gc current grant 2-way、gc cr grant busy。

3.4 同城 A 中心 2 节点、同城 B 1节点

测试时间 50 分钟，5000 并发会话连接，测试过程中观察到 TPS（吞吐量）、IOPS（每秒IO读写次数）、RT（响应时间）、CPU 使用情况等数据，结果如下：

另外针对数据库指标分析如下：

如上图总体资源利用率，3节点压力也较均匀。

如上图集群相关等待事件汇总情况，平均等待 4,146,727.87 秒，总计 12,440,183.62 秒，占 DB time 的 87.13%。

如上图集群相关等待事件明细情况，同城 A 中心 2 节点、同城 B 中心 1 节点压测时，在 top event 中出现了 9 种集群类等待事件，分别为gc buffer busy acquire、gc cr block lost、gc current block busy、gc current grant busy、gc cr block 3-way、gc cr block 2-way、gc current grant 2-way、gc current block 2-way、gc current block lost。

4 压测结果分析汇总

根据上表汇总结果，从集群相关指标来看，4 节点时集群等待事件平均等待时间为 489,312.23 秒，等待时间最小，同中心 2 节点平均等待时间为 1,586,569.06 秒，不同中心 2 节点平均等待时间为 4,263,328.07 秒，是同中心的三倍，双中心 3 节点平均等待时间为 4,146,727.87 秒，也是同中心 2 节点的三倍；从集群类等待事件的种类来看，4 节点压测时 top event 中出现了 8 种不同的集群类等待事件，同中心 2 节点压测只出现了 4 种不同的集群类等待事件，而不同中心 2 节点压测则出现了 7 种，双中心 3 节点压测出现了 9 种不同的集群类等待事件。

针对以上压测数据以及上表相关指标分析，可选方案要么为同中心2 节点 RAC，要么为双中心 4 节点 RAC；最后再结合目前生产数据库的实际情况，综合评估推荐使用同中心两节点 RAC 作为最终的生产架构。本次测评则使用同城 A 两节点 RAC 及同城 B 单机 ADG 架构，此架构性能最优且有较好的高可用保障， 但是面对机房级的灾难时，要比双中心 4 节点 RAC 稍逊一筹。由于 RAC 数据库在使用的过程中，不可避免的会进行节点间数据（数据块、消息）传输，这对于不同机房的两节点 RAC 来说可能会是个很大的压力，当然 4 节点中的各个节点交叉传输数据也是不可避免的需要跨机房进行，这块对于私网要求是很高的。

最后，由于个人经验不足，第一次使用 Swingbench 进行 RAC 压力测试，存在一定的实验偏差，对于 AWR 报告的阅读及指标分析也存在一定的不足之处，如果您有不同意见或建议，可以添加我个人微信【JiekeXu_DBA】一起交流，近期打算新开通一个微信交流群，由于文章缺少留言功能，可直接在微信群中交流数据库相关技术和文章，也会邀请更多技术大牛一起交流，相互学习,谢谢！

欢迎关注我的公众号【JiekeXu DBA之路】，第一时间一起学习新知识！
————————————————————————————
公众号：JiekeXu DBA之路
CSDN ：https://blog.csdn.net/JiekeXu
墨天轮：https://www.modb.pro/u/4347
腾讯云：https://cloud.tencent.com/developer/user/5645107
————————————————————————————