Oracle SuperCluster T5-8 上的 Oracle Fusion Distributed Order Orchestration

作者：Thomas Varghese 和 Pushkar Upakare

作为一个完备的集成系统，Oracle SuperCluster T5-8 代表了部署 Oracle Fusion Distributed Order Orchestration 应用的理想平台。在 Oracle 执行的测试中，优化后的半机架 Oracle SuperCluster T5-8 在创建的订单行数方面提供了近乎线性的可扩展性，同时系统资源利用率仍然很低。

2014 年 10 月发布

简介

Oracle Fusion Distributed Order Orchestration 是下一代 Oracle Fusion Supply Chain Management (SCM) 应用，旨在提供集中订单处理、集中监视和异常管理，以及忠实执行可预测的订单执行策略。该系统改善了各种不同订单捕获和履行环境中的订单编排。Oracle Fusion Distributed Order Orchestration 提供了集中管理的编排策略和履行监视。这些功能协同工作，有利于提高盈利能力和客户满意度，同时大幅降低履行成本、减少订单错误。

面对不可预测的需求时，扩展可靠的订单执行至关重要。订单执行系统故障或订单处理性能低下可能导致收入损失，严重损害品牌形像。因此，组织的基础架构需要能够处理如今的负载，同时可以根据需要轻松扩展以满足未来需求，无需复杂、耗时的重新配置过程。基础架构还必须支持高可用性，提供弹性，并且能够经受住故障考验并从容恢复。

在 Oracle SuperCluster T5-8 上部署 Oracle Fusion Distributed Order Orchestration 代表了一个极具吸引力的解决方案，可以根据需要可预测地扩展订单创建速度。为了评估该解决方案的性能，Oracle 工程师测试了半机架 Oracle SuperCluster T5-8 系统，将其扩展至关键组件的多个实例，以提供更高的吞吐量。将 Oracle SuperCluster 中的各个组件组成集群可满足可用性要求，有助于确保持续运行和故障切换。根据测试结果，该系统横向扩展了 Oracle Fusion Distributed Order Orchestration 和 Oracle SOA Suite 的实例数，展示了可预测的近乎线性的可扩展性。Oracle SuperCluster 平台的可扩展性意味着它有足够的空间来存放更多订单。

Oracle SuperCluster T5-8

Oracle SuperCluster T5-8 是一个多用途集成系统，它经过统一设计、测试和集成，可运行任务关键型企业应用和迅速部署云服务，同时可实现超高的效率、显著的成本节省和极致性能。它非常适合包含 Web、数据库和应用组件在内的多层级企业应用。这个系统不但通用，还具有强大的、内置的零开销虚拟化功能，从而成为适用于整合 SCM 中常见的大量应用、数据库和中间件负载的理想平台。图 1 显示为测试 Oracle Fusion Distributed Order Orchestration 而配置的 Oracle SuperCluster T5-8。

Oracle SuperCluster T5-8 这个集成系统旨在承载整个软件解决方案体系，它包括以下组件：

• Oracle SPARC T5-8 服务器。SPARC T5-8 服务器提供大内存容量和高度集成的设计，该设计支持任务关键型应用的虚拟化和整合。用于 Oracle 融合分布式编排测试的半机架 Oracle SuperCluster 配置有两个四处理器 SPARC T5-8 服务器，每个服务器配有 1 TB 系统内存。
• Oracle Exadata Storage Server。为增强 Oracle Database 性能，提供了 Oracle Exadata 存储技术。该平台是提高 Java 中间件和应用、通用应用以及 Oracle Database 11g 第 2 版性能的理想之选。
• Oracle ZFS 存储设备。集成式 Oracle ZFS 存储设备使用支持闪存的混合存储池加快应用响应速度。该设备具有基于文件的 I/O 的性能可扩展性，并且易于管理，是在 Oracle SuperCluster 内管理共享应用数据文件的不二之选。
• Oracle Sun Datacenter InfiniBand Switch 36。此 InfiniBand 交换机提供高吞吐量、低延迟和可扩展的结构，适合流程间通信、网络和存储的结构整合。InfiniBand 为 Oracle Real Application Clusters (Oracle RAC) 提供的每秒事务数 (TPS) 比千兆以太网 (GbE) 网络多 63%。Oracle SuperCluster 中有三个 InfiniBand 交换机，提供系统内的专用连接。
• 集成的零成本虚拟化。Oracle VM Server for SPARC（以前称为 Sun Logical Domains 或 LDoms）与 Oracle Solaris Zones 结合使用，可提高安全性、利用率和可靠性。

图 1 显示针对以下各节所述测试而配置的半机架 Oracle SuperCluster T5-8。

图 1. 半机架 Oracle SuperCluster T5-8 上部署的 Oracle 融合应用产品。

半机架 Oracle SuperCluster T5-8 为扩展 Oracle 融合分布式订单执行提供了一个有效的平台。它所具有的一些重要技术功能可提供高性能、低延迟的可扩展性。

• Oracle SPARC T5 处理器可提供显著的计算空间，允许随着需求的增长添加虚拟化服务器实例来服务更多的订单。
• Oracle 的零成本虚拟化解决方案（包括 Oracle Solaris 区域和 Oracle VM Server for SPARC）意味着可以轻松细分、虚拟化和隔离系统资源，从而以可预测的性能实现大量整合。
• Oracle Exadata Storage Server 作为 Oracle SuperCluster 的一部分提供，其 Exadata 智能闪存缓存特性会智能地将数据库对象缓存到闪存中，并用速度更快的闪存操作取代较慢的机械式磁盘 I/O 操作。
• Oracle SuperCluster 的所有组件均通过高速、低延迟的 InfiniBand 网络连接，减少了 Oracle 分布式订单执行的延迟。

SPARC T5-8 服务器

在半机架 Oracle SuperCluster T5-8 内，Oracle VM Server for SPARC 用于将两台 SPARC T5-8 服务器中的每一个分为应用域和数据库域。这些域再通过系统内部的高性能、低延迟的 InfiniBand 网络连接到 Oracle Exadata Storage Server。

应用域

在应用域中，使用 Oracle Solaris 区域进一步对 SPARC T5-8 服务器资源进行分区。

• 两台 SPARC T5-8 服务器上的 Oracle 融合应用产品均运行在应用域中的一个区域内。此环境最终用于容纳扩展解决方案所需的 SCM 和 Oracle Fusion Distributed Order Orchestration 实例。
• Oracle HTTP Server 运行在其中一台服务器（节点 1）上的一个单独区域中，提供基于 Web 的系统访问。
• Oracle 身份管理运行在第二台服务器（节点 2）上的一个单独区域中，使组织能够有效地管理所有企业资源上的用户身份的整个生命周期。

数据库域

Oracle RAC 11g 第 2 版是 Oracle Database 的集群版本，在数据库域中运行。Oracle RAC 使用共享缓存、集群数据库架构，克服了传统无共享和共享磁盘架构的局限性，无需更改现有 Oracle Database 应用即可为数据库提供高性能、可扩展性和可靠性。

Oracle Exadata Storage Server

Oracle SuperCluster T5-8 中提供的 Oracle Exadata Storage Server 配置如下，通过单独的磁盘组为 Oracle RAC 数据库实例提供数据库加速：

• Oracle 融合应用产品磁盘组
• Oracle Internet Directory 磁盘组
• Oracle 身份管理磁盘组

Oracle ZFS 存储设备

Oracle SuperCluster 中使用 Oracle ZFS 存储设备提供非数据库存储。该设备是一个混合存储系统，基于独特的以缓存为中心的架构，拥有大量 DRAM 和闪存，多线程对称多处理 (SMP) 操作系统为其提供支持。因此，70% 到 90% 的 I/O 操作通常源自设备上的 DRAM，这有助于整合数据密集型负载。在此测试部署中，目录层和应用层利用 Oracle ZFS 存储设备上的存储。

测试和结果

为了评估性能，使用 Loadrunner 向半机架 Oracle SuperCluster T5-8 施加预定义的模拟负载。用每小时订单创建 TPS 来测量性能。随着负载增加，分配额外的横向扩展主机，并收集一些指标来监视和评估系统性能随负载增加的变化。

负载说明

图 2 显示了典型的订单生命周期。销售订单由多行组成，通常每个订单平均有 5 到 6 行项目。编排流程由多个履行步骤组成，分配给一个或多个订单行。

图 2. Oracle Fusion Distributed Order Orchestration 的典型订单生命周期。

在 Oracle 进行的测试中，这个客户代表场景的服务负载为 59 KB，每各订单两行项目。行项分组在一个装运集中。在此测试场景中，接收和分解订单；然后，编排引擎通过一个两步骤流程处理行项。该过程首先将两个行项安排为一个组（装运集）。安排成功之后，执行信用检查。信用检查采用 Oracle Fusion Distributed Order Orchestration 的模板任务层 (TTL) 特性。最后，继续订单行处理，直至结束。

Oracle Fusion Distributed Order Orchestration 应用利用了处理约束框架和 Oracle Business Rules 框架，可由最终用户扩展。为了帮助处理业务流程，内置了一些现成的普遍适用的约束和 Oracle 业务规则。根据不同的功能需求，适用的规则和约束将在订单生命周期的不同阶段执行。这确保了下游服务（如订单承诺和信用检查）获得与功能有关的输入。在这个代表场景中，订单处理过程中执行了 17 条内置的 Oracle 业务规则和 12 条内置的处理约束。还对 33 条属于订单头和订单行的重要功能属性执行了属性交叉引用。

Oracle Fusion Distributed Order Orchestration 基础架构支持多个并发用户同时提交订单。Oracle 工程师通过模拟数百个虚拟用户，每个虚拟用户按配置好的频率和模式提交订单，模拟了这种现实生活中的情况。

性能结果

通过横向扩展专用于处理 SCM（Oracle Fusion Distributed Order Orchestration/Oracle SOA Suite）的虚拟主机数（横向扩展主机）来执行测试。测试了一个、两个、三个和四个虚拟主机的配置。如图 3 所示，每分钟创建订单数实现了近乎线性的可扩展性，四个横向扩展节点高峰时每分钟创建近 10000 个订单。

图 3. 增加 Oracle Fusion Distributed Order Orchestration 节点数在每分钟创建订单数方面提供了近乎线性的可扩展性。

表 1 提供了测试的详细信息，列出了平均每小时订单创建 TPS。

应用域和 Oracle RAC 节点上的资源利用率

尽管 Oracle SuperCluster T5-8 产生了近乎线性的可扩展性，但应用域内运行的横向扩展节点上的系统资源利用率仍为中等水平，为额外的可扩展性预留了相当大的空间。图 4 显示 Oracle Fusion Distributed Order Orchestration 和 Oracle SOA Suite 上运行的四个横向扩展主机各自的 CPU 利用率百分比。负载在四个节点之间分布得非常均匀。CPU 利用率任何时候都未超过 50%。

图 4. 随着节点的增加和订单创建数的扩展，CPU 利用率保持中等水平，这表明有相当大的空间余量。

两个 Oracle RAC 节点上的系统资源利用率也保持中等水平。图 5 显示四节点测试期间 Oracle RAC 节点上的 CPU 利用率百分比。同样，此图显示资源利用率分布均匀，运行状态稳定，仍留有相当大的空间余量。

图 5. 即使用四个节点运行 Oracle Fusion Distributed Order Orchestration，Oracle RAC 节点上 CPU 利用率百分比仍保持中等水平。

在 Oracle SuperCluster 上部署 Oracle Fusion Distributed Order Orchestration

Oracle Fusion Distributed Order Orchestration 构建于开放的、基于标准的、面向服务的架构之上，可实现灵活的集成和降低总拥有成本 (TCO)。Oracle 测试中使用了以下软件版本：

• Oracle Solaris 11 (11.1 SRU7.5)
• Java Development Kit (JDK) 1.6 u71
• Oracle Identity Management Server
• Oracle RAC 11g 第 2 版 (11.2.0.3)
• Oracle 融合应用产品第 7 版 P22（包括 Oracle HTTP Server、Oracle SOA Server、Fusion Applications Distributed Order Orchestration Server、Oracle Fusion Global Order Promising Server、Fusion Applications Advanced Planning Server、SCM Common Server）
• Oracle 融合应用产品 Distributed Order Orchestration 补丁（18076574、18157443、18272928、18891548）

图 6 提供有关如何部署半机架 Oracle SuperCluster T5-8 来测试 Oracle Fusion Supply Chain Management 的其他详细信息。

• 数据库域配有 256 GB RAM 和一个 16 核 SPARC T5-8 处理器。
• 应用域配有 768 GB RAM 和三个 16 核 SPARC T5-8 处理器，共计 48 核。

部署架构考虑了高可用性要求，虚拟化技术为处理器、内存等资源的管理和分配提供了相当大的灵活性。

部署活动分为三个重要阶段，如以下各节所述：

• 部署 Oracle RAC 和 Oracle Exadata Storage Server
• 利用 Oracle WebLogic Server 域部署 Oracle 融合身份管理基础架构
• 利用第二个 Oracle WebLogic Server 域作 SCM，部署 Oracle 融合应用产品

图 6. Oracle SuperCluster T5-8 上部署的 Oracle Fusion Distributed Order Optimization。

部署 Oracle RAC 和 Oracle Exadata Storage Server

数据库域配置为包含以下 Oracle RAC 数据库，如图 6 所示：

• FUSIONDB1 和 FUSIONDB2 包含 Oracle 融合应用产品事务型数据库。
• OIDDB1 和 OIDDB2 包含 Oracle Internet Directory 的身份和策略存储。
• IDMDB1 和 IDMDB2 用于 Oracle 融合中间件中的 Oracle Identity Manager、Oracle Access Manager、Oracle SOA Suite 和 Oracle Metadata Services。

Oracle 身份管理和 Oracle 融合应用产品模式通过 Oracle 融合中间件提供的 Repository Creation Utility 加载到各 Oracle RAC 数据库实例中。数据库实例使用 Oracle 自动存储管理来管理数据存储。

对于每个数据库实例，在 Oracle Exadata Storage Server 中创建两个磁盘组：

• DATA 磁盘组用于存储数据文件。
• REDO 磁盘组用于重做文件。

配置中有四台 Oracle Exadata Storage Server，每台服务器有 12 个磁盘，共计 48 个磁盘。假定存储服务器上采用正常冗余，共计有 18 GB 可用空间。要创建一个 300 GB 网格磁盘意味着每个磁盘驱动器将贡献约 17 GB 存储（300 GB / 18 GB = 约 17 GB）。

部署 Oracle 融合身份管理基础架构

Oracle 融合身份管理部署通过选择 Oracle 融合中间件部署拓扑 (EDG) 来完成，如图 7 所示。该部署基于 EDG 拓扑建议并使用以下组件：

• 它使用 6 个 Oracle Solaris 区域部署 Oracle Internet Directory、Oracle Identity Manager、Oracle Access Manager 组件和 Oracle HTTP Server 的 Web 层实例。（这些组件的逻辑布局如图 6 中的 OID1、OID2、IDM1、IDM2、OHS1 和 OHS2 项所示。）
• Oracle Traffic Director（图 6 中的 OTD 项）用于满足 EDG 拓扑的负载平衡器要求。它部署在一个专用 Oracle Solaris 区域中。也可以使用基于硬件的负载平衡器。
• Oracle Internet Directory 实例是双活部署。
• Oracle Access Manager、Oracle Identity Manager 和 Oracle SOA Suite 服务器及 Oracle Fusion Distributed Order Orchestration 和 Oracle SOA Suite 服务器（图 6 中的 DOO/SOA1–DOO/SOA4 项）。图 6 中的 SOA1–SOA4 项是双活部署。
• Oracle WebLogic 管理服务器是单活配置。
• 目录层和应用层使用 Oracle ZFS 存储设备提供的相同的共享存储。

有关企业部署拓扑的更多详细信息，请参见“企业部署参考拓扑简介”。

图 7. 选择 EDG 拓扑并为各组件指定相应的主机名。

Oracle 融合应用产品的 Oracle Identity Manager 的推荐部署拓扑基于以下重要事项：

• 为身份和访问服务提供高可用性和可扩展性。
• 每个组件均配置为一个集群。
• 每个组件均与自己的计算机名关联。
• 根据可用资源，计算机名可以分配给同一台服务器或不同的服务器。
• 虚拟主机名和 IP 地址用于服务重定位。
• Oracle WebLogic 服务器配置为监听虚拟 IP 地址。

配置包含三个主层，使用 Oracle Solaris 区域虚拟化。

• 目录层
• 应用层
• Web 层

目录层

目录层是所有 LDAP 服务所在的部署层。此层包括 Oracle Internet Directory 和 Oracle Virtual Directory 等产品。目录层由目录管理员管理，提供企业 LDAP 服务支持。目录层与数据层紧密联系。Oracle Internet Directory 依赖 Oracle Database 作为其后端。

Oracle 评估的部署中使用了以下配置：

• 身份和策略存储信息保存在同一个数据库中。
• 采用单独的 Oracle RAC 数据库作为 Internet Directory 以及身份和访问管理的数据存储。
• 以独占方式使用 Oracle Directory Server。
• 两个 Oracle Directory Server 实例位于两个 Oracle Solaris 区域中：LDAPHOST1 (etc27-z11) 和 LDAPHOST2 (etc27-z12)。

应用层

应用层是部署 Java EE 应用的层。Oracle Identity Manager、Oracle Identity Federation、Oracle Directory Services Manager 和 Oracle Enterprise Manager Fusion Middleware Control 等产品是可以部署在该层的关键 Java EE 组件。这层中的应用特别受益于 Oracle WebLogic Server 的高可用性支持，配置如下：

• IDMHOST1 (etc27-z9) 和 IDMHOST2 (etc27-z10) 安装了 Oracle Identity Manager 和 Oracle SOA。Oracle Identity Manager 是一个用户供应应用。此拓扑中部署的 Oracle SOA 专用于为 Oracle Identity Manager 提供工作流功能。
• Oracle Enterprise Manager Fusion Middleware Control 通过 Oracle Platform Security Services 代理与 Oracle Access Manager 集成。
• Oracle WebLogic Server 控制台、Oracle Enterprise Manager Fusion Middleware Control 和 Oracle Access Management 控制台始终绑定到管理服务器的监听地址。
• Oracle WebLogic 管理服务器是单例服务。它一次只在一个节点上运行。如果发生故障，它会在可用节点上重新启动。
• IDMHOST1 (etc27-z9) 上的 WLS_ODS1 托管服务器和 IDMHOST2 (etc27-z10) 上的 WLS_ODS2 托管服务器位于一个集群中，Oracle Directory Services Manager 应用的目标是该集群。
• IDMHOST1 (etc27-z9) 上的 WLS_OAM1 托管服务器和 IDMHOST2 (etc27-z10) 上的 WLS_OAM2 托管服务器位于一个集群中，Oracle Access Manager 应用的目标是该集群。
• Oracle Directory Services Manager 绑定到 WLS_ODS1 和 WLS_ODS2 托管服务器的监听地址。默认情况下，这些托管服务器的监听地址分别设置为 IDMHOST1 (etc27-z9) 和 IDMHOST2 (etc27-z10)。
• IDMHOST1 (etc27-z9) 上的 WLS_OIM1 托管服务器和 IDMHOST2 (etc27-z10) 上的 WLS_OIM2 托管服务器位于一个集群中，Oracle Identity Manager 应用的目标是该集群。
• IDMHOST1 (etc27-z9) 上的 WLS_SOA1 托管服务器和 IDMHOST2 (etc27-z10) 上的 WLS_SOA2 托管服务器位于一个集群中，Oracle SOA 应用的目标是该集群。
• IDMHOST1 (etc27-z9) 上的 WLS_OIF1 托管服务器和 IDMHOST2 (etc27-z10) 上的 WLS_OIF2 托管服务器位于一个集群中，Oracle Identity Federation 应用的目标是该集群。

Web 层

Oracle HTTP Servers 部署在 Web 层。为支持使用 Oracle Application Server Single Sign-On 和 Oracle Access Manager 等产品执行企业级一次性登录，需要 Web 层。
在 Web 层，进行了以下配置：

• WEBHOST1 (etc27-z7) 和 WEBHOST2 (etc27-z8) 安装了 Oracle HTTP Server、WebGate（一个 Oracle Access Manager 组件）和 mod_wl_ohs 插件模块。mod_wl_ohs 插件模块支持将请求从 Oracle HTTP Server 代理到应用层中运行的 Oracle WebLogic Server。
• Oracle HTTP Server 11g 和 WebGate for Oracle Access Manager 使用 Oracle 访问协议 (OAP) 与 Oracle Identity Manager 中立区域 (DMZ) 中的 IDMHOST1 (etc27-z9) 和 IDMHOST2 (etc27-z10) 上运行的 Oracle Access Manager 通信。Oracle HTTP Server 11g 和 WebGate for Oracle Access Manager 用于执行用户身份验证等操作。

部署 Oracle 融合应用产品

本节概述 Oracle 融合应用产品部署。更多深入信息，请参见 Oracle 融合应用产品安装指南。

为 Oracle 融合应用产品创建供应配置文件过程中所选拓扑是“每个应用和中间件组件一个主机”，如图 8 所示。此拓扑在部署 Oracle 融合应用产品方面提供了最大的灵活性。

图 8. Oracle 融合应用产品提供部署拓扑选择。

该配置选择创建了公共域主机与 SCM 域主机分离的拓扑。该域进一步分为主要主机和次要主机。主要主机包含 SCM 域的管理服务器。次要主机包含所有托管服务器，如 SCM 通用服务器、Oracle Product Information Management 服务器、Oracle Cost Management 服务器、Oracle Fusion Distributed Order Orchestration 服务器、Logistics 服务器、Oracle Advanced Planning 服务器、Oracle SOA 服务器等。全球订单处理 (GOP) 服务器托管在与 Oracle Advanced Planning and Scheduling 服务器关联的次要节点上。

该解决方案的通用元素定义如下：

• 原始主机。原始主机是公共域（具体来说是公共域的管理服务器）所在的位置。每个环境中只有一个原始主机。
• 主要主机。主要主机是域的管理服务器运行的位置。一个域中只有一个主要主机。
• 次要主机。次要主机是任何应用的托管服务器所在的位置（当它们与同一域的管理服务器不在相同主机上时）。次要主机 一词仅当域跨多个物理服务器时才有意义。没有管理服务器的一个或多个服务器被称作次要主机。

该部署的一些关键要点如下：

• 完成初始供应之后，添加了次要横向扩展主机。横向扩展主机包含一个 Oracle SOA 托管服务器和一个 Oracle Fusion Distributed Order Orchestration 托管服务器。
• 这些主机个个都在 Oracle Solaris 区域中，如图 6 所示。
• 使用硬分区创建资源池，资源池中有一些处理器，并向资源池添加次要区域和关联的横向扩展主机。
• Oracle SOA Suite 服务器横向扩展需要在 Java Message Service 服务器端做特定更改。集群中的每个 Oracle SOA 服务器使用共享文件夹上的一个单独文件。有关横向扩展 Oracle SOA Suite 服务器的详细说明，请参见“横向扩展 Oracle SOA Suite 服务器的附加配置过程”。
• 这些区域通过 InfiniBand 网络通信。经由 InfiniBand 监听器建立与 Oracle RAC 数据库的 JDBC 连接。

图 9 显示原始主机 (etc27-z18) 的配置。

图 9. 配置原始主机。

图 10 显示主要主机 (etc27-z20) 和次要主机 (etz27-z21) 的配置。

图 10. 配置主要主机和次要主机。

图 11 显示 Oracle HTTP Server (etc27-z19) 的 SCM Web 层实例的配置，该服务器托管在 Oracle Solaris 区域上。

图 11. 配置 Oracle HTTP Server 的 SCM 实例。

调优建议

虽然完整的调优和表布局不在本文讨论范围内，但以下各节将概要介绍 Oracle 在 Oracle SuperCluster T5-8 上测试 Oracle Fusion Distributed Order Orchestration 过程中使用的调优实践。

Oracle HTTP Server 调优

对 ifModule mpm_work_module 进行了一些 Oracle HTTP Server 调优，如下所示。

# worker MPM
# StartServers: initial number of server processes to start
# MaxClients: maximum number of simultaneous client connections
# MinSpareThreads: minimum number of worker threads which are kept spare
# MaxSpareThreads: maximum number of worker threads which are kept spare
# ThreadsPerChild: constant number of worker threads in each server process
# MaxRequestsPerChild: maximum number of requests a server process serves
# Specify "ServerLimit nnn" before MaxClients if MaxClients/ThreadsPerChild > 16.
# Specify "ThreadLimit nnn" before MaxClients if ThreadsPerChild > 64.
<IfModule mpm_worker_module>
ThreadLimit        64
ServerLimit        512
StartServers         20
MaxClients        20000
MinSpareThreads    3200
MaxSpareThreads     4800
ThreadsPerChild    48
MaxRequestsPerChild  0
AcceptMutex fcntl
LockFile "/var/tmp/http_lock"
</IfModule>

Oracle 融合应用产品调优

对 SCM 中的各种应用要素进行调优以优化所测试配置的性能，如以下各节所述。

修改 SCM 域托管服务器的内存参数

SCM 应用中的每个域都有自己的一组属性，这些属性在域的配置目录中的 fusionapps_start_params.properties 文件中指定。有关 fusionapps_start_params.properties 的更多详细信息，请参见这个优秀的博客。

对于 fusionapps_start_params.properties 文件中的以下各项，更改其名称和值对。如果名称不存在，则应添加到文件。

• #Fusion Default Sysprops
  
  

  fusion.default.default.sysprops=-Dapplication.top=${WL_HOME}/../applications/scm/deploy 
  -Djbo.ampool.minavailablesize=1 -Djbo.doconnectionpooling=true 
  -Djbo.load.components.lazily=true -Djbo.max.cursors=5 -Djbo.recyclethreshold=75 
  -Djbo.txn.disconnect_level=1 -Djps.auth.debug=false -Doracle.fusion.appsMode=true 
  -Doracle.notification.filewatching.interval=60000 -Dweblogic.SocketReaders=3 
  -Dweblogic.security.providers.authentication.LDAPDelegatePoolSize=20 -Djps.authz=ACC 
  -Djps.combiner.optimize.lazyeval=true -Djps.combiner.optimize=true 
  -Djps.policystore.hybrid.mode=false -Djps.subject.cache.key=5 
  -Djps.subject.cache.ttl=600000 
  -Ddiagfwk.diagnostic.test.location=${WL_HOME}/../applications/jlib/diagnostic,
  ${ATGPF_ORACLE_HOME}/archives/applications/diagnostics -Doracle.multitenant.enabled=false 
  -Doracle.jdbc.createDescriptorUseCurrentSchemaForSchemaName=true        
  -Dapplication.config.location.ocm=${FA_INSTANCE_HOME}/ocm  
  -Dweblogic.security.SSL.trustedCAKeyStore=/u01/oracle/instance/keystores/fusion_trust.jks  
  -Dweblogic.mdb.message.MinimizeAQSessions=true  
  -Dweblogic.ejb.container.MDBDestinationPollIntervalMillis=6000 
  -Dweblogic.http.client.defaultReadTimeout=300000 
  -Dweblogic.http.client.defaultConnectTimeout=300000 
  -DHTTPClient.socket.readTimeout=300000 -DHTTPClient.socket.connectionTimeout=300000 
  -Dwebcenter.owsm.gpa.enabled=true -Dprovisioning.start.params.processed=true 
  -DXDO_FONT_DIR=${WL_HOME}/../applications/../bi/common/fonts 
  -Dweblogic.LoginTimeoutMillis=50000
  

• #SCM Domain Admin Server
  
  

  fusion.AdminServer.SunOS-sparc.memoryargs=-XX:PermSize=1g -XX:MaxPermSize=1g 
  -XX:+UseParallelGC  -XX:+HeapDumpOnOutOfMemoryError  
  -XX:HeapDumpPath=${FA_INSTANCE_HOME}/debug -XX:+ParallelGCVerbose 
  -XX:ReservedCodeCacheSize=128m -XX:+UseParallelOldGC  -XX:ParallelGCThreads=2
  

• #Advanced Planning Server
  
  

  fusion.AdvancedPlanningCluster.SunOS-sparc.memoryargs=-XX:PermSize=256m 
  -XX:MaxPermSize=512m -XX:+UseParallelGC  -XX:+HeapDumpOnOutOfMemoryError  
  -XX:HeapDumpPath=${FA_INSTANCE_HOME}/debug -XX:+ParallelGCVerbose 
  -XX:ReservedCodeCacheSize=128m -XX:+UseParallelOldGC  -XX:ParallelGCThreads=4  
  -XX:+UseCompressedOops -XX:StringTableSize=500009
  

• #Cost Management Server
  
  

  fusion.CostManagementCluster.SunOS-sparc.memoryargs=-XX:PermSize=256m 
  -XX:MaxPermSize=512m -XX:+UseParallelGC  -XX:+HeapDumpOnOutOfMemoryError  
  -XX:HeapDumpPath=${FA_INSTANCE_HOME}/debug -XX:+ParallelGCVerbose 
  -XX:ReservedCodeCacheSize=128m -XX:+UseParallelOldGC  -XX:ParallelGCThreads=4 
  -XX:StringTableSize=500009
  

• #Order Orchestration Server
  
  

  fusion.OrderOrchestrationCluster.SunOS-sparc.memoryargs=-XX:PermSize=756m 
  -XX:MaxPermSize=756m -XX:+UseParallelGC  -XX:+HeapDumpOnOutOfMemoryError  
  -XX:HeapDumpPath=${FA_INSTANCE_HOME}/debug -XX:+ParallelGCVerbose 
  -XX:ReservedCodeCacheSize=128m -XX:+UseParallelOldGC  -XX:+UseCompressedOops 
  -XX:ParallelGCThreads=20 -XX:LargePageSizeInBytes=2g -XX:StringTableSize=500009 
  -Xnoclassgc -XX:-UseAdaptiveSizePolicy
  

• #SCM Common Server
  
  

  fusion.SCMCommonCluster.SunOS-sparc.memoryargs=-XX:PermSize=256m 
  -XX:MaxPermSize=756m -XX:+UseParallelGC   -XX:+HeapDumpOnOutOfMemoryError 
  -XX:HeapDumpPath=${FA_INSTANCE_HOME}/debug -XX:+ParallelGCVerbose 
  -XX:ReservedCodeCacheSize=128m -XX:+UseParallelOldGC -XX:ParallelGCThreads=4 
  -XX:StringTableSize=500009
  

• #SCM SOA Server
  
  

  fusion.SCM_SOACluster.SunOS-sparc.memoryargs=-XX:PermSize=756m 
  -XX:MaxPermSize=756m -XX:+UseParallelGC  -XX:+HeapDumpOnOutOfMemoryError  
  -XX:HeapDumpPath=${FA_INSTANCE_HOME}/debug -XX:+ParallelGCVerbose 
  -XX:ReservedCodeCacheSize=128m -XX:+UseParallelOldGC -XX:+UseCompressedOops 
  -XX:ParallelGCThreads=20 -XX:LargePageSizeInBytes=2g -XX:StringTableSize=500009   
  -Xnoclassgc -XX:-UseAdaptiveSizePolicy
  

• #Added Sysprops for AdvancedPlanningCluster
  
  

  fusion.AdvancedPlanningCluster.SunOS-sparc.sysprops=
  -Dweblogic.ejb.container.MDBDestinationPollIntervalMillis=6000 
  -Dweblogic.mdb.message.MinimizeAQSessions=true
  

• #Added Sysprops for OrderOrchestrationCluster
  
  

  fusion.OrderOrchestrationCluster.SunOS-sparc.sysprops=
  -Dweblogic.ejb.container.MDBDestinationPollIntervalMillis=6000 
  -Dweblogic.mdb.message.MinimizeAQSessions=true    
  

• #Memory Changes for each Servers
  
  

  fusion.SCMDomain.AdminServer.default.minmaxmemory.main=-Xms12g -Xmx12g
  fusion.SCMDomain.AdvancedPlanningCluster.default.minmaxmemory.main=-Xms4g -Xmx4g
  fusion.SCMDomain.CostManagementCluster.default.minmaxmemory.main=-Xms512m -Xmx2048m
  fusion.SCMDomain.LogisticsCluster.default.minmaxmemory.main=-Xms512m -Xmx2048m
  fusion.SCMDomain.OrderOrchestrationCluster.default.minmaxmemory.main=-Xms16g -Xmx16g -Xmn6g
  fusion.SCMDomain.SCM_SOACluster.default.minmaxmemory.main=-Xms12g -Xmx12g -Xmn4608m
  

JDBC 调优

设置 JDBC 数据源参数（数据库池除外）的常规方式是登录管理服务器控制台，执行以下步骤：

1. 在 Domain Structure 树中，展开 Services，然后选择 Data Sources。
2. 在 Summary of Data Sources 页面中，选择数据源。
3. 在 Administration Console 的 Change Center 中，单击 Lock and Edit。
4. 在“Settings for <DataSourceName>”页面中，转到 Configuration -> Connection Pool。
5. 设置 Initial Capacity、Maximum Capacity 和 Minimum Capacity。
6. 展开“advanced”属性视图，设置 Shrink Frequency。
7. 单击“Save”保存设置。
8. 单击 Change Center 中的“Activate Changes”。

JDBC 数据源中的连接池包含一组由应用保留、使用并在随后返回池中的 JDBC 连接。连接池和其中的连接在注册连接池时创建，通常是在启动 Oracle WebLogic Server 或将数据源部署到新目标时。在 Oracle 执行的测试中，config.xml 文件修改如下：

DB pool(DataSourceName-rac1, DataSourceName-rac2)
SOALocalTxDataSource:Initial Capacity=500, max capacity=3500, min capacity=500
JRFWSAsyncDSAQ:  Initial Capacity=50, max capacity=300, min capacity=50
ApplicationServiceDB: Initial Capacity=150, max capacity=400, min capacity=150
SOADataSource: Initial Capacity=500, max capacity=3500, min capacity=500
mds-ApplicationMDSDB: Initial Capacity=50, max capacity=300, min capacity=50
ApplicationDB: Initial Capacity=150, max capacity=2000, min capacity=150
EDNSource: Initial Capacity=50, max capacity=100, min capacity=50
EDNDataSource: Initial Capacity=50, max capacity=100, min capacity=50


Shrink frequency: 600s
ApplicationDB
ApplicationServiceDB
JRFWSAsyncDSAQ
mds-ESS_MDS_DS
mds-soa
SOADataSource
SOALocalTxDataSource
mds-ApplicationMDSDB
mds-CustomPortalDS

消息驱动的 Bean (MDB) 调优

对于 MDB 池设置，增加了空闲池中的最大 bean 数，如图 12 所示。执行了以下步骤：

1. 登录管理控制台。
2. 选择 Lock and Edit，然后选择 Deployments（在左侧导航器中）。
3. 选择应用，找到名称以 AsyncRequestProcessorMDB 和 AsyncResponseProcessorMDB 结尾的 MDB。
4. 对于每一个，单击 MDB，然后选择 Configuration 选项卡。
5. 将空闲池中的最大 bean 值更改为 15。
6. 对请求和响应重复此过程。
7. 单击 Save。
8. 对 Oracle Distributed Order Applications 和应用产品服务器重复这些步骤。

图 12. 配置 MDB 池设置。

Oracle SOA Suite 调优

在 Oracle SOA Suite 中，线程线经过优化以提高性能。在 Oracle Enterprise Manager Console 上执行以下步骤来设置 Oracle 业务流程执行语言 (BPEL) Process Manager：

1. 依次选择 Farm_SCMDomain、SOA 和 SOA-infra，然后选择 SOA Administration。
2. 选择 BPEL Properties。
3. System threads 设置为 5，BPEL Engine Threads 设置为 400，BPEL Invoke Threads 设置为 300。

对于调解器线程，从 Oracle Enterprise Manager Console 执行以下过程：

1. 依次选择 Farm_SCMDomain、SOA 和 SOA-infra，然后选择 SOA Administration。
2. 选择 Mediator Properties。
3. Parallel Worker Threads 数设为 20。

要设置 Oracle SOA Suite 的 Oracle 事件传递网络 (EDN) 的线程，从 Oracle Enterprise Manager Console 执行以下过程：

1. 依次选择 Farm_SCMDomain、SOA 和 SOA-infra，然后选择 SOA Administration。
2. 选择 System Mbean 浏览器，然后选择 Application defined Mbean。
3. 接下来选择 oracle.as.soainfra.config，然后是 Server：soa_server-x。
4. 最后选择 EDNConfig，然后是 EDN。
5. EDN 线程数设为 40。

Oracle Global Order Promising Server 调优

为增强 Oracle Global Order Promising Server，编辑 gopServerConfig.xml 文件 (instance/gop_1/config/GOP/GlobalOrderPromisingServer1/gopServerConfig.xml) 并添加以下代码：

<num-msg-autosave>1000000</num-msg-autosave>

在该文件中，还需要将 -finest 级别更改为事件错误日志记录：

<logLevel>INCIDENT_ERROR</logLevel>

Java.security 调优

切换 java.home/lib/security 目录下 java.security 文件中的安全提供者，如下所示：

security.provider.1=sun.security.provider.Sun
security.provider.2=sun.security.pkcs11.SunPKCS11${java.home}/lib/security/sunpkcs11-solaris.cfg
security.provider.3=sun.security.rsa.SunRsaSign

网络调优

对于横向扩展区域和 SCM Oracle HTTP Server 区域，使用 ndd 实用程序执行以下命令：

# ndd -set /dev/tcp tcp_conn_req_max_q 96000
# ndd -set /dev/tcp tcp_conn_req_max_q0 64000
# ndd -set /dev/tcp tcp_xmit_hiwat 524288
# ndd -set /dev/tcp tcp_recv_hiwat 524288
# ndd -set /dev/tcp tcp_naglim_def 1
# ndd -set /dev/tcp tcp_smallest_anon_port 10000
# ndd -set /dev/tcp tcp_time_wait_interval 6000

Oracle RAC 调优

Oracle Fusion Applications for SCM 要求对数据库进行一定程度的调优以获得最佳性能。对于 Oracle 执行的测试，在以下领域进行了调优：

• 通过 init.ora 文件修改 init 参数（如下所示）
• 对 Oracle Fusion Distributed Order Orchestration 和 Oracle SOA Suite 的特定表进行分区
• 使用 BLOB 安全文件重新创建业务线 (LOB) 段
• 收集某些表上的优化器统计信息
• 使用全局哈希分区重新创建 SOA-INFRA 和 Oracle Fusion Distributed Order Processing 特定的索引

对 init.ora 文件进行了一些重要更改，如下所示：

_gc_defer_time=0
_gc_policy_time=0
_gc_undo_affinity=FALSE
filesystemio_options=SETALL

open_cursors=500
sga_target=64G 
pga_aggregate_target=8G 
shared_pool_size=4G 

nls_sort=BINARY
open_cursors=500
session_cached_cursors=500
plsql_code_type=NATIVE
processes=15000
db_securefile=ALWAYS

Redo log file size=4 files of 20GB each

总结

Oracle SuperCluster T5-8 上部署的 Oracle Fusion Distributed Order Orchestration 代表了极具吸引力的解决方案架构。Oracle SuperCluster 平台以完善、集成的系统形式提供计算、存储和网络，这就可以将 Oracle Fusion Distributed Order Orchestration 应用和所需其他组件部署在一个高性能、低延迟的平台中。本文所述测试证明了 Oracle SuperCluster 可以显著提高 Oracle Fusion Distributed Order Orchestration 应用的性能和可靠性，具有近乎线性的可扩展性并留有相当大的系统空间。

另请参见

• Oracle 融合应用产品安装指南 提供了有关如何安装 Oracle 融合应用产品的更多信息。
• “企业部署参考拓扑简介”提供了有关 Oracle 融合应用产品企业部署拓扑的更多详细信息。
• “横向扩展 Oracle SOA Suite 服务器的附加配置过程”提供了有关横向扩展 Oracle SOA Suite 服务器的详细说明。

关于作者

Thomas Varghese 是首席软件工程师，自 2005 年起即在 Sun 和 Oracle 工作，其工作领域包括 Java 性能、身份管理和 SAP Netweaver 体系集成。在其约 15 年的技术经验中，他最开始是一名开源工程师，主要工作领域为用于 XML 绑定的 Java 架构 (JAXB) 之前的 XML 数据绑定领域。目前，他主要从事 Oracle 硬件上的各种 Oracle 企业应用的调优、选型和基准测试。

在过去 16 年间，Pushkar Upakare 一直为 Oracle 工作，目前他担任 Oracle Fusion Distributed Order Orchestration 团队的应用架构师。他还与 Oracle 融合中间件团队、Oracle 融合性能、可扩展性和可靠性团队以及 Oracle 融合移植团队密切合作，实施各种选型、调优和基准测试以满足高需求和可用性要求。

笔者特别鸣谢 Oracle 融合中间件团队和 Oracle 融合性能、可扩展性和可靠性团队对此项目的贡献。

关注我们：
博客 | Facebook | Twitter | YouTube