ATP上运行APEX的OCPU数量配置最佳实践咨询

Oracle Autonomous Transaction Processing（ATP）的sessions、open_cursors等初始化参数由Oracle托管自动维护，不支持用户手动修改，参数值会随OCPU数量的调整线性动态调整，完全匹配当前配置的计算资源承载能力。

核心资源对应规则 #

每1个OCPU对应最多300个并发数据库会话，每个会话默认支持最多300个打开游标，OCPU扩容后对应参数会自动同步上调，无需额外操作。

规划最佳实践 #

• 先基于业务负载测算基准需求
  非活跃的APEX登录会话不会占用数据库会话，仅用户发起页面请求、数据提交、报表查询等操作时，才会从ORDS连接池获取数据库连接。先统计业务的峰值并发请求数，结合单次请求平均占用数据库连接的时长，折算需要的最大并发数据库会话数，按照每OCPU支撑300个会话的比例倒推基础OCPU配置，额外预留至少20%的冗余应对突发流量。
• 重度计算场景额外提升配置
  如果APEX应用包含大量复杂PL/SQL逻辑执行、多表关联大报表查询、批量数据同步等高CPU消耗的操作，不能仅参考会话数测算结果，需要参考测试环境的CPU利用率数据规划：建议生产环境峰值CPU利用率不超过70%，如果测试环境100个并发高消耗请求会占用1个OCPU 70%的计算资源，那么500个同类型并发请求至少需要配置8个OCPU（基础需求+20%冗余）。
• 不同环境差异化配置
  • 开发环境：仅面向10人以内开发团队使用时，最低配置1个OCPU即可满足需求
  • 测试环境：压测用环境建议至少配置生产环境50%的OCPU规格，方便准确评估生产环境的资源需求
  • 生产环境：面向内部员工使用的低频应用最低2个OCPU起步，面向公网用户的公开应用建议最低4个OCPU起步，保障高可用性和流量缓冲空间。
• 上线后动态调整
  ATP支持无停机在线调整OCPU数量，前期可以按评估的最低需求配置，上线后前2周重点监控三个指标：最大会话数、CPU利用率、游标使用率，如果连续3天峰值指标超过阈值（会话数超过当前OCPU对应上限的80%、CPU利用率超过70%、游标使用率超过80%），再按需扩容OCPU即可，无需前期过度配置产生不必要的成本。

额外注意事项 #

调整ORDS连接池的jdbc.MaxLimit参数时，不要超过当前OCPU对应最大会话数的80%，避免出现会话耗尽报错，同时避免连接数过多导致CPU资源争抢。

内容的提问来源于stack exchange，提问作者Nilay Panchal