Oracle 19c RAC 不同架构下压测性能对比分析
作者 | JiekeXu
来源 |公众号 JiekeXu DBA之路（ID: JiekeXu_IT）
如需转载请联系授权 | (个人微信 ID：JiekeXu_DBA)
大家好，我是 JiekeXu,很高兴又和大家见面了,今天和大家一起来看看 Oracle 19c RAC 不同架构下压测性能对比分析，欢迎点击上方蓝字“JiekeXu DBA之路”关注我的公众号，标星或置顶，更多干货第一时间到达！
1 背景描述
针对目前的某 Oracle 核心库升级到 19c 的项目，通过对不同架构下的 RAC 进行压力测试，最终确定升级后生产环境的架构选择。基于此目的，对于压测结果着重分析集群相关的指标。
2 压测方案说明
利用工具 Swingbench 进行测试，Swingbench 是一个免费的负载生成器和基准测试工具，其支持 Oracle 数据库（11g、12c、18c、19c），以前写过一篇压测工具的使用，感兴趣的可以戳此查看。Swingbench 的开发目的主要是展示 RAC 的负载和测试，也可用于单实例环境。Swingbench 模拟了一套订单业务逻辑，通过创建 SOE 用户，模拟产品和订单业务，然后自定义数据量 50G 的大小，本次测试生成 50GB 的业务数据，在准生产环境新 19c 物理机下模拟并发数为 5000 的并发测试。四台物理机版本和数据库配置如下：
| 节点 IP | OS | CPU/Memory | SGA/PGA |
|---|---|---|---|
| 192.16.75.131 | RHEL7.8 | 144c/512g | 200g/50g |
| 192.16.75.132 | RHEL7.8 | 144c/512g | 200g/50g |
| 192.16.75.133 | RHEL7.8 | 144c/512g | 200g/50g |
| 192.16.75.134 | RHEL7.8 | 144c/512g | 200g/50g |
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 分钟。
| 节点 IP | 方案一 | 方案二 | 方案三 | 方案四 |
|---|---|---|---|---|
| 192.16.75.131 | √ | √ | √ | |
| 192.16.75.132 | √ | √ | ||
| 192.16.75.133 | √ | √ | √ | |
| 192.16.75.134 | √ | √ | √ |
3 压测结果分析
3.1 双中心 4 节点 rac
测试时间 50 分钟，5000 并发会话连接，测试过程中观察到 TPS（吞吐量）、IOPS（每秒IO读写次数）、RT（响应时间）、CPU使用情况等数据，结果如下表：
| TPS | RT | IPOS | 平均 CPU 使用率 | 平均活跃会话 | 集群等待时间 |
|---|---|---|---|---|---|
| 17567 | 123796 | 1148598 | 99% | 1500 | 489312 |
另外针对数据库指标分析如下：
如上图总体资源利用率有倾斜，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 使用情况、集群等待时间等数据，结果如下：
| TPS | RT | IPOS | 平均 CPU 使用率 | 平均活跃会话 | 集群等待时间 |
|---|---|---|---|---|---|
| 16435 | 104459 | 1189467 | 88% | 2300 | 1586569 |
另外针对数据库指标分析如下：
如上图总体资源利用率，两节点压力较均匀。
如上图集群相关等待事件汇总情况，平均等待 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 使用情况等数据，结果如下：
| TPS | RT | IPOS | 平均 CPU 使用率 | 平均活跃会话 | 集群等待时间 |
|---|---|---|---|---|---|
| 16691 | 110489 | 1528353 | 99% | 2200 | 4263328 |
另外针对数据库指标分析如下：
如上图总体资源利用率，两节点压力较均匀。
如上图集群相关等待事件汇总情况，平均等待 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 使用情况等数据，结果如下：
| TPS | RT | IPOS | 平均 CPU 使用率 | 平均活跃会话 | 集群等待时间 |
|---|---|---|---|---|---|
| 16691 | 110489 | 1528353 | 99% | 2200 | 4263328 |
另外针对数据库指标分析如下：
如上图总体资源利用率，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 压测结果分析汇总
| TPS | RT | IPOS | 平均 CPU 使用率 | 平均活跃会话 | 集群等待时间 | Total DB Time | 集群等待时间 DB Time 占比 | |
|---|---|---|---|---|---|---|---|---|
| 双中心 4 节点 | 17567 | 123796 | 1148598 | 100% | 1500 | 489312 | 229022 | 14.24% |
| 同城 A 中心 2 节点 | 16435 | 104459 | 1189467 | 88% | 2300 | 1586569 | 279897 | 18.29% |
| 同城 A 同城 B 各 1 节点 | 16691 | 110489 | 1528353 | 99% | 2200 | 4263328 | 230743 | 61.59% |
| 双中心 3 节点 | 16691 | 110489 | 1528353 | 99% | 2200 | 4263328 | 237950 | 87.13% |
根据上表汇总结果，从集群相关指标来看，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】一起交流，然后由于文章缺少留言功能，近期新开通一个微信交流群，可直接在微信群中交流数据库相关技术和文章，也会邀请更多技术大牛一起交流，相互学习,如有需要的可添加我个人微信，备注：加群，谢谢！
---------------------------------------
全文完，希望可以帮到正在阅读的你，如果觉得此文对你有帮助，可以分享给你身边的朋友，同事，你关心谁就分享给谁，一起学习共同进步~~~
另外免费开放 QQ 群，用于文件资料共享，闲时吹水，感兴趣的朋友可扫码进入，谢谢！
欢迎关注我的公众号【JiekeXu DBA之路】，第一时间一起学习新知识！
———————————————————————————
公众号：JiekeXu DBA之路
CSDN ：https://blog.csdn.net/JiekeXu
墨天轮：https://www.modb.pro/u/4347
腾讯云：https://cloud.tencent.com/developer/user/5645107
———————————————————————————
分享几个数据库备份脚本
Oracle 表碎片检查及整理方案
OGG|Oracle GoldenGate 基础2022 年公众号历史文章合集整理Oracle 19c RAC 遇到的几个问题
OGG|Oracle 数据迁移后比对一致性利用 OGG 迁移 Oracle11g 到 19C
OGG|Oracle GoldenGate 微服务架构
Oracle 查询表空间使用率超慢问题一则
Oracle 11g升级到19c需要关注的几个问题
国产数据库|TiDB 5.4 单机快速安装初体验
Oracle ADG 备库停启维护流程及增量恢复
Linux 环境搭建 MySQL8.0.28 主从同步环境