简体中文版经机器翻译而成，仅供参考。如与英语版出现任何冲突，应以英语版为准。

性能验证和基准测试结果

08/18/2025 贡献者

此次性能验证的目的不是为了树立任何标记。相反，如果您遵循本文档中概述的部署过程和最佳实践，您可以期望在公共云中部署 Oracle 数据库获得类似的性能指标。

我们使用 Swingbench 销售订单输入 (SOE) 模块来模拟 OLTP 类型的工作负载，并将工作负载应用于部署到具有 NFS 协议上的 FSx 存储卷的 M5 EC2 实例的 Oracle 数据库。默认的 Swingbench SOE I/O 配置文件接近 80/20 读/写分割，这接近真实的 OLTP Oracle 工作负载配置文件。

随着客户端执行销售订单输入、浏览、库存查询等操作的并发用户数量的增加，工作负载也会随之增加。测试的数量分别为 8、16、32、64 和 128 个并发用户。 Swingbench 使用的算法在服务器端很繁重，以推动合理的交易量并测试 Oracle 服务器的极限。我们观察到，当并发用户数为 128 时，EC2 实例的 CPU 利用率达到容量的大约 80-90%。

以下部分提供了设置和测试结果的详细信息。

测试环境设置

计算

我们部署了一个 EC2 M5 实例，它有 8vCPU、32G RAM 和 10Gps 的网络带宽。

该图显示输入/输出对话框或表示书面内容

FSx 存储

我们创建了三个数据库卷，并使用 NFS 将卷挂载到 EC2 实例上，如下所示：

/u01——Oracle 二进制文件
/u02——Oracle数据文件、控制文件
/u03——Oracle日志文件、控制文件

我们保留了关键控制文件的两个副本以实现冗余。

该图显示输入/输出对话框或表示书面内容

FSx 文件系统配置了 80,000 IOPS 容量和 2GiBps I/O 吞吐量。

Oracle 配置

我们安装了带有 RU 补丁 19.8 的 Oracle 版本 19c。服务器上启用了 dNFS。

该数据库被部署为具有三个 PDB 的容器化数据库。我们使用一个 PDB 实例进行性能测试。下图显示了 NFS 挂载点上的 Oracle 存储大小。

该图显示输入/输出对话框或表示书面内容

Swingbench 配置

我们在具有 8vCPU 和 32G RAM 的 Windows 主机上部署了 Swingbench 2.6（最新版本）。我们使用 SOE plsql 测试模块版本 2 作为基准。默认负载配置文件提供 80/20 的读/写比率来模拟现实世界的 OLTP 事务工作负载。

我们使用的模式比例因子为 50，它提供了 160G 的初始数据加载大小和 30G 的临时空间分配。在这个规模因素下，SOE 模式提供了 1000 个仓库和 5000 万个客户来模拟在线订单处理。

以下屏幕截图演示了 Swingbench Windows UI 中的工作负载配置文件和典型的事务运行指标。

该图显示输入/输出对话框或表示书面内容

如该图所示，在整个测试运行过程中，交易水平一直保持在同一水平。

测试结果分析

我们捕获了每次测试运行的 Swingbench 结果并获得了相应的 Oracle AWR 报告以进行性能分析。

从最终用户的角度，我们关注交易量和用户响应时间等关键指标。这两个指标都显示了在给定并发登录系统的用户数量的情况下，用户可以从销售订单输入系统执行的交易数量，以及用户输入订单后完成交易和收到响应的速度。

从 Oracle 服务器端，我们解析了 Oracle AWR 报告，以确定可能减慢用户事务速度的顶级等待事件。前 10 个 Oracle 等待事件表明，在 Swingbench 模拟事务测试运行期间，Oracle 服务器主要受 I/O 限制，数据库时间的 50%-60% 都花在 db file sequential read。 `log file sync`也是一个促成因素，因为事务提交会导致 Oracle 日志记录过程将日志 I/O 从缓冲区缓存刷新到磁盘上的日志文件，尽管它在数据库时间百分比级别上是一个较小的因素。

我们绘制了用户交易量、用户响应时间和 Oracle 顶部等待事件与事务运行期间的并发用户数的图表。结果如下所示：

该图显示输入/输出对话框或表示书面内容