Oracle 大页面、AMM和ASMM的最佳组合所需的建议，用于在负载测试期间处理繁重的工作负载

嗨，

我们目前正在对基于JAVA和Oracle的应用程序进行负载测试。主要处理发生在数据库端。应用程序是一个基于web的借贷平台。以下是详细信息:

1.应用程序服务器-运行在具有16核/64gb RAM的AWS EC2虚拟机上的Jboss 6.1.0
2. DB服务器-Oracle 11g SE1 (11.2.0.4) 托管在具有16核/64gb RAM的AWS RDS上
3.负载测试使用apache jmeter 3.3与400虚拟用户同时使用和执行应用程序上的活动

自过去2个月以来，我们一直在执行此练习，并基于多个ADDM和AWR报告，我们在代码级别进行了适当的调整，我们看到了agr的改进。响应时间和查询不是ADDM/AWR报告。

我们达到了任何代码级别调整都不会影响avg的阶段。负载测试中获得的响应时间。因此，我们开始一个接一个地玩DB参数。到目前为止，更改以下参数可带来良好的性能改进:

1. cursor_sharing设置为强制
2.使用大页面启用
3. sga_target从25GB增加到30gb
4. sga_max_size从25GB增加到30gb
5. memory_target从37GB增加到40gb

默认情况下，memory_max_target为48gb。pga_aggregate_target未设置 (0)

我们现在开始面临的问题是，当我们将SGA增加到任何> 30GB的值时，以avg增加的形式观察到巨大的性能下降。负载测试报告中的响应时间。ADDM和AWR报告中报告的主要等待事件包括:

1.共享池锁存器-库缓存: 互斥X，库缓存锁，锁存器: 行缓存对象
2.硬解析
3.由于无效而导致的硬解析

在推荐apt方面需要援助。上述参数的值，以便我们可以充分利用给定的硬件平台并消除这些等待。

提前谢谢。

既然您关注的是应用程序性能，那么如果

cursor_sharing set to FORCE


提供好处，那么你真的应该首先解决这个问题，即，你的应用程序没有使用绑定变量。就解析和SGA访问而言，这是一个开销。

对于较大的系统，我们通常建议 * 反对 * 全内存管理，因此您要设置:

sga_target
pga_aggregate_target

并且 * 不 * 设置memory_target参数。

同样，对于大型会话计数和大型SGA，那么巨大的页面是毫无疑问的。